From brian@dxcoms.cern.ch Wed May 11 15:17:55 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA15951 for ; Wed, 11 May 1994 09:18:31 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08660; Wed, 11 May 1994 15:17:57 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21114; Wed, 11 May 1994 15:17:55 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405111317.AA21114@dxcoms.cern.ch> Subject: COMMERCIALIZING INTERNET? [Orig: Internet Economics....] - comp.infosystems.www #15733 (fwd) To: ipng@cmf.nrl.navy.mil Date: Wed, 11 May 1994 15:17:55 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 13323 Folks, In case you have not seen this (re IPng accounting requirement) Brian [forwarding trail deleted] ---------- Forwarded message ---------- Date: Thu, 5 May 1994 09:28:44 -0500 Reply-To: H-Net Political History discussion list Sender: H-Net Political History discussion list From: H-Pol Co-moderator Peter Knupfer Subject: NETNEWS: Internet Economics: Will user fees be necessary? To: Multiple recipients of list H-POL TAXPAYER ASSETS PROJECT - INFORMATION POLICY NOTE May 3, 1994 This is a note about an important issue: the future pricing of Internet services. Please repost freely. - University of Michigan Economist Hal Varian says the Internet is likely to face some type of usage based pricing in the future. - Varian says increasing demands on Internet by multimedia applications and commercial bypass of telephone networks will lead to significant increases in demands on Internet resources, and create pressures for usage based pricing models. - Varian proposes a system of congestion based pricing, that will allow free off-peak usage, but speculates that other outcomes are possible, and - Predicts eventual demise of CIX model of flat rate (no settlements) pricing for Network Service Providers. NOTES ON PROFESSOR HAL VARIAN'S APRIL 21 TALK ON INTERNET ECONOMICS by James Love (love@essential.org) May 3, 1994 On April 21, the Telecommunications Policy Roundtable (TPR) held its first workshop on the future of democratic discourse on the Internet. Hal Varian, a professor of economics and finance from the University of Michigan, presented "Economic FAQs about the Internet," a paper co-authored with Jeffery K. Mackie-Mason. The Workshop was held at the Carnegie Institution in Washington, DC, and attended by about 60 persons. There was considerable interest in the topic. TAP had received more than 400 requests for copies of the paper (including about 350 requests by electronic mail). The paper is available for anonymous ftp, gopher, or World Wide Web at gopher.econ.lsa.umich.edu, or by sending an email message to ndaly@essential.org. Professor Varian's prepared talk followed the paper fairly closely, with a number of facts and antidotes thrown in to illustrate his main points. Among economists Varian is known as a superb expositor, and his presentation was as clear and accessible as the paper. Varian spent the first part of his talk describing such topics as who "owns" various components of the Internet (backbones, midlevel networks, etc), technical aspects of Internet routing, and the growth of traffic on the Internet. I won't bother to go over all the points which are explained in the paper, but a few items are worth mentioning. Varian disclosed that Internet data packets contain an unused "priority bit," that was originally designed to allow Military brass to assign priorities in data routing. The costs of routers (workstations) had fallen much faster than the long distance transport costs, and the long distance backbone facilities were often the bottleneck. Varian also spent a good amount of time explaining how Internet usage is changing, and that while electronic mail is the service most widely used, it constitutes only about 8 percent of the bits sent over the network. New applications, such as the multimedia Mosaic, Internet Fax, and Internet radio are rapidly becoming large users of Internet resources, and these new uses of the Internet are creating huge pressures to change the way Internet services are priced. To illustrate his point, Varian talked about the new Power PCs, which will allow a single user (a college student talking to his parents) to hook up a video camera, and send about 1 megabyte of data per second to the Internet, nearly tying up an entire T-1 line. Varian indicated that the power of workstations connected to the Internet is increasing much faster than the capacity of the Internet to carry traffic. Moveover, a number of commercial users of the Internet are rapidly finding ways to bypass the higher priced telephone networks, both domestically and internationally. Varian was focused largely on the increased congestion cause by the new demands on the Internet. Interestingly, his own research indicated that peak demands shifted from day to day, and peak and off-peak usage could not be easily predicted by the time-of-day, as it is for telephone service. In the United States the Internet is unregulated, and there are no internal prices for Internet usage. Network service providers typically buy bandwidth, or capacity, and face zero marginal costs for usage. End users face a variety of charges, depending upon how their service providers resell access to the network. Some foreign countries, such as New Zealand and Chile, charge Internet users for traffic, as measured by bits. Different uses for Internet services have different requirements in terms of routing priorities. Electronic mail generally does not require an immediate claim on network bandwidth, and can be managed to travel "off peak." On the other hand, some services, such as video conferencing, Internet "talk," or running Mosaic, generally allow the user to command bandwidth at a particular time. Varian was quite clear that he believes that the problem of congestion on the Internet will become a much larger problem as the Internet becomes used for a more diverse set of applications (and the growing power of desktop computers to generate data). Varian said that he believes there will eventually be prices for Internet usage, and the only real uncertainty will be which pricing system is used. A very difficult problem will be the development of accounting systems and other mechanisms to facilitate billing for Internet usage. Generally speaking, it is not simple to determine if data packets contain electronic mail, fax transmissions, video, or other data, making content based pricing problematic. There are also a number of complex issues relating to when or where traffic would be "charged" for internet usage, since users gain access to the Internet from a highly decentralized network of workstations and networks. Varian also talked about problems in determining if senders or receivers would pay for data transmissions, which he illustrated by talking about ftp or gopher servers (who was the "sender" of the data, the person sending the query, or the file server which returns data?). According to Varian, a number of persons are working on these problems, and many important decisions will be determined by engineers working on technical issues. He singled out the Internet Society's Internet Engineering Task Force as the most important forum for groups sorting these issues out. Varian said that any scheme to charge for internet usage would also involved non-trivial costs in terms of metering or accounting, and possibly significant changes in the culture of the Internet (the question on many persons minds is the future of the Internet Listserves), although on a more optimistic note, he said the costs of routing and backbone services should be low, if calculated on a per user basis. Varian said little about the Commercial Internet Exchange (CIX) in his prepared remarks, but in response to questions, he said that he did not believe the CIX pricing model (a flat fee for connectivity) was sustainable, and he thought that the new Network Access Point (NAP) providers (Ameritech, Pac Bell, Sprint, and MFS) would employ a usage based pricing approach. Varian also talked at some length about work underway to create mechanisms for charging for other types of transactions, using a variety of schemes to create "virtual cash" for use on the Internet, such as the services recently announced by Commerce Net using technology developed under NSF funded R&D. Varian said that government R&D in this area was welcomed, because it provided neutral non-proprietary systems that couldn't be controlled or manipulated by a single firm. Varian described the new Internet architecture, which is based upon four NAPs, each controlled by a telephone company, which Varian described as the new "cloverleaves" for the Internet (connecting various backbones and networks), and the new vBNS high speed backbone. Varian said the high interest in the vBNS contract was due largely to its strategic role in the development of new Internet technologies, including accounting and payment mechanisms, which may eventually be deployed to the entire Internet. (MCI "won" the recent NSF contract for the vBNS, but the award is being contested by Sprint. AT&T was also rumored to have been an unsuccesful bidder on the vBNS). Varian's own preference for Internet pricing is a system that only charges for priority routing. As described in several papers (written with MacKie-Mason), Varian would employ a system whereby users would "bid" for access when congestion was a problem, and routers would give priority to packets that had the highest willingness to pay. Users would pay the lowest price that was accepted in this routing "auction," so everyone would have an incentive to reveal their true willingness to pay. Under Varian's scheme, all Internet traffic which did not claim priority status would travel for free. Thus, for example, a large Internet mailing list such as Humanist, PACS-L or CPSR- Announce could mail for "free," with an off peak priority. For Varian's scheme to work, it would be necessary to have routers compare "bids" by packets, priority bidders would have to "pay" for access to someone, and there would have to be a high degree of consensus, so the priority packets would not face bottlenecks or delays anywhere on the Internet. Varian acknowledged that it was possible that the Varian (and MacKie- Mason) system of pricing might not be adopted, and some less elegant system, such as pricing by the bit, may be coming. A number of persons wanted to know who would decide these issues, and Varian was not too specific. The message (the "guess") seemed to be that the companies which controlled the NAPs and a critical mass of the backbones would have a lot to say about what was eventually adopted. Varian was asked to speculate about future telco investments in Internet providers, such as purchases of companies like PSI or UUNET, but he was reluctant to predict much, other than to emphasize the importance of competitive free entry into the market for Internet services, which would undermine monopolist practices. Varian was asked if it was possible that a coalition of Internet providers would have the power to implement a pricing scheme that would have an adverse impact on the future of Internet listserves (many of which "send" more than 100,000 messages per day), but he was reluctant to be very specific in his predictions, other than to say that many outcomes were possible. Note: On April 29, a follow-up workshop was held with Dr. Steve Wolff of NSF, Professor David Farber, and PSI CEO William Schrader. Notes from that workshop and other information regarding Internet pricing will be posted to tap-info. --------------------------------------------------------------------- TAP-INFO is an Internet Distribution List provided by the Taxpayer Assets Project (TAP). TAP was founded by Ralph Nader to monitor the management of government property, including information systems and data, government funded R&D, spectrum allocation and other government assets. TAP-INFO reports on TAP activities relating to federal information policy. tap-info is archived at ftp.cpsr.org; gopher.cpsr.org and wais.cpsr.org Subscription requests to tap-info to listserver@essential.org with the message: subscribe tap-info your name --------------------------------------------------------------------- Taxpayer Assets Project; P.O. Box 19367, Washington, DC 20036 v. 202/387-8030; f. 202/234-5176; internet: tap@essential.org +---------------------------------------------------------------+ | Earl Babbie ][ BABBIE@NEXUS.CHAPMAN.EDU ][ CIS:76424,156 | | Chapman University, Orange CA 92666 ][ Voice: 714-997-6565 | +---------------------------------------------------------------+ ********************************************************************** * Sharron S. Humenick Humenick@UWYO.EDU * * School of Nursing, University of Wyoming * * Box 3065 Phone 307-766-2319 * * Laramie, Wyoming 82071-3065 Fax: 307-766-6821 * ********************************************************************** -- =============================================================================== | Hibatur Rahman Ahmad | http://www.lehigh.edu/hra2/public/www-data/hra2.html | =============================================================================== From kasten@mailserv-D.ftp.com Wed May 11 09:44:36 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA16227 for ; Wed, 11 May 1994 09:46:02 -0400 Received: from ftp.com by ftp.com ; Wed, 11 May 1994 09:45:55 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 11 May 1994 09:45:55 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA22213; Wed, 11 May 94 09:44:36 EDT Date: Wed, 11 May 94 09:44:36 EDT Message-Id: <9405111344.AA22213@mailserv-D.ftp.com> To: brian@dxcoms.cern.ch Subject: Re: COMMERCIALIZING INTERNET? From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 1099 > NOTES ON PROFESSOR HAL VARIAN'S APRIL 21 TALK > ON INTERNET ECONOMICS >.... Somewhat interesting. My only real comment is that a) the criteria keep the current operating 'priciple' of 'cooperative anarchy' and b) with the network services criterion, we should have the ability to sort packets into various classes - we do not mention what the classes are but presumably, the classification structure would be fairly flexible and dynamic. So, since the Internet would remain a cooperative anarchy, some providers can do flat-rate charging, others can do free access, others can do usage based charging, others can do Varian's "bidding". By having a flexible packet classification structure, we could tag packets as to whether we are willing to pay for their carriage or not, and how much, and so on. My conclusion is that the criteria seem to provide for all the needed elements to build an accounting scheme such as Varian described, or any other scheme. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From scoya@CNRI.Reston.VA.US Thu May 12 15:44:14 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA25887 for ; Thu, 12 May 1994 15:45:38 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11776; 12 May 94 15:44 EDT To: ipng@cmf.nrl.navy.mil Subject: DRAFT Minutes from May 9 Teleconference Date: Thu, 12 May 94 15:44:14 -0400 From: Steve Coya Message-ID: <9405121544.aa11776@IETF.CNRI.Reston.VA.US> DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference May 9, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Steve Bellovin / AT&T Jim Bound / DEC Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Eric Fleischman / Boeing Paul Francis / NTT Mark Knopper / Ameritech Greg Minshall / Novell Frank Kastenholz / FTP Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- Ross Callon / Wellfleet Dave Clark / MIT Craig Partridge / BBN 1. The directorate approved the minutes of the teleconference held on April 25. Coya to place into IETF Shadow directories, and send copies of the minutes to the IAB and IESG. 2. A verbal roll call was taken to ascertain who would be at the retreat. Of those on the call, all were planning to attend except for Jon Crowcroft and Brian Carpenter (Brian will attend via phone). Coya to probe the three directorate members who did not participate in the call to see if they will be attending the retreat. 3. Allison announced that she and Scott had prepared an IPNG track for the Toronto IETF meeting. 4. Scott provided a brief summary of what occurred in the IPNG area during Interop in Vegas, and mentioned some upcoming meetings where there will be an IPNG panel. Allison summarized what would/could be happening at the INET meeting in Prague. 5. Allison outlined what is expected in the technical reviews being done by the directorate. Everyone was polled, and those who have not yet submitted their reviews stated they would have something soon, some by next week, all will be done prior to the retreat. 6. Frank Kastenholz reviewed some of the comments/suggestions received about the requirements document. Following with tradition, each item was discussed in minute detail as/when mentioned :-) 7. The desire for a good revision of the requirements document, to be available as a reference point in time for the retreat, was reiterated. The document will be frozen and released in its final form just after the retreat. 8. The directorate stated that each candidate should bring a paper copy of their own document set. A suggestion that the decision be made based on the least amount of documentation (i.e simplicity speaks for itself) was greeted with mirth, but was not adopted by the directorate. Quote du jours: It was not marketing material per se, but was without content and presented in an upbeat manner. From J.Crowcroft@cs.ucl.ac.uk Fri May 13 09:15:45 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA29104 for ; Fri, 13 May 1994 04:16:18 -0400 Message-Id: <199405130816.EAA29104@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 13 May 1994 09:15:48 +0100 To: ipng@cmf.nrl.navy.mil Subject: Re: IPng Architecure and an IPng Architect Date: Fri, 13 May 94 09:15:45 +0100 From: Jon Crowcroft I believe we have all the pieces of an architecture, but perhaps i have perceived them as a whole, where maybe i'm either wrong, or else that perception is hard when yo uare closer to the IETF than me. Pieces come from the work that has gone on in some of the research groups now for some time, and more recently in working groups. There is a clear overlap between these pieces, and they way some of them should be implemented, actually goes a long way to addressing some of the base points in the IPng requirements document. note that once upon a time, the requirements used to be split into the basic ones, routing & addressing, and the 'frills' we would add since if we are doing an IPng, we must get a number of things in at this opportunity as there is no other. However, we now have a set of requirements hich i believe interlock very nicely, and lead towards a unified architecture that is self supporting. key pieces are not the boring details of addresses (eid and paths etc) and routes; key pieces are: Flows, as per integrated services wg, and the papers from scott shenker, dave clark, lizia zhang, both in int-serv, and at various SIGCOMM and other conferences. Multicast, as in the DVMRP, then MOSPF and CBT, and now PIM work. Resource Reservation - the specification of flows to routers i na robust, but non virtual circuit way, wisely independent of unicast or multicast routing algorithm. Security: the IAB retraet produced a report which cites the use of a lower layer ID (flow) authenticated, as of use for access control, authentication, assistance in prevention of traffic analysis etc etc Talking to a lot of commercial customers, their view of the requirement is biased towards these latter problems, and NOT the simple matter of address space and router table management. [because of the amount of commercial and multimedia traffic expected, e.g. from reuters, telerate, the financial times, e.g. from the BBC, e.g. from teaching, healthcare]. If you can authenticate the flow id, and instatiate the state in routers, you buy the network multi-service support, link sharing, and all the rest. You also buy fast packet forwarding. A lot of this is expressed in Nimrod, but I find that the way it is there is hard to digest at the moment. Once this is a basic building block, the format of the fields that actually build a path is largely irrelevant, provided there are enough bits, since they are not referenced often. However, there is one major constraint on them from elksewhere that does bite: migration. if you buy the idea of interworking IPv4 and IPng, rather than dual stack, then a handy format is important. Personally, I belive dual stack is unacceptable for financial reasons, unless someone can show me why interworking is more expesnive, and given our expierence of interworking colouirred book, ISO and IPv4, i doubt they will. so, while i am not going to write a review of all the proposals, I believe it is quite obvious what the consclusion of what i'm saying is. on the matter of accounting, obviously a reasoanble authenticated flow gives to low cost accounting. since the current favoured models of billing by people who actually understand the economics of such things (e.g. scott shenker, or Hal Varian) favours a 3 tier system: 1 best effort traffic continues to be datagram, but should be serveed round robin (with random early drop or similar) or any queueing scheme that attmepts to do statistically even share - other traffic comes into 2 categroies. 2. stuff that is best effort QoS (i.e. if there is capacity, provide the QoS, otherwise degrade) and 3. absolute QoS (predictive or guaranteed) whether there is congestion or not. charging for internet should be fixed, except for the last or last two classes... we have work in hand to head towards this, so we need the change control to make it happen over the next 3 years as we evolve ipng.... we probably want a minimum of legacy code in routers....but what do i know about routers anyhow... regards jon From sob@hsdndev.harvard.edu Sat May 14 23:10:21 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA08329 for ; Sat, 14 May 1994 23:10:26 -0400 Date: Sat, 14 May 94 23:10:21 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405150310.AA14303@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: another white paper Network Working Group S. Bellovin IPng White Paper AT&T Bell Laboratories Experimental 14 May 1994 The Shape of the Bits Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550 Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. 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 munnari.oz.au to learn the current status of any Internet Draft. Overview and Rational The existing debate has focused on SIPP versus TUBA versus CATNIP. Some people point to existing support for TUBA-like headers, while others point to SIPP's ease of parsing. But those are the wrong things to look at. To look at the headers is to focus on the shape of the bits. But that is all but irrelevant. With a few exceptions, detailed near the end of this memo, bits can be filed, hammered, glued, bent, and otherwise worked into the proper shape. What is of interest is what those bits do, regardless of what they look like. In this memo, I will attempt to extract the salient areas of difference. It may be that the best choice for IPng can be synthesized, not by merging two or three of the candidates, but by selecting among the different philosophical aspects in the different areas. The areas discussed here are security, address formats, and Bellovin [Page 1] White Paper The Shape of the Bits 14 May 1994 transition. The analysis for autoconfiguration and routing is similar. Security Services SIPP's security protocol is derived from SP3. It uses encapsulation of the payload, and a SAID to select a key, algorithm, etc. TUBA's security protocol is derived from NLSP, which is derived from SP3. By a curious coincidence, it, too, uses encapsulation of the payload, and a SAID to select a key, algorithm, etc. In other words, the two IPng candidates use a virtually identical security mechanism. The most significant semantic difference is the existence of a sequence number in the SIPP version, to provide some protection against replay. But the existence of such sequence numbers -- and the question is quite controversial -- is orthogonal to any IPng issues. For now, we should assume an encapsulating security protocol, and pick the shape later. A more difficult question, and one that is relevant to this directorate, is what aspects of a security protocol should be mandatory. On the one hand, IPv4 has none, and the Internet is surviving (though in some cases just barely) without one. On the other hand, there have been calls for universal cryptographic authentication. A complicating factor is the plethora of legal restrictions on the import, use, or export of cryptographic technology. SIPP's routing headers make security more urgent. But if similar functionality is added to TUBA, say to support mobility, the same need will arise. I therefore recommend that support for an authentication encapsulation be mandatory with IPng -- whichever candidate is chosen. The scope is not yet clear; it may be desirable to have it operable gateway-to-gateway or user-to-user as well as the more obvious host-to-host. I regard it as mandatory that IPng be firewall-friendly. TUBA is somewhat nicer in this regard, since SIPP's nested headers make it harder to find the transport header for filtering. With either, an encapsulating encryption protocol hides such information. I recommend that both header formats be augmented to include a transport header pointer. This field would be adjusted as necessary to accomodate options or headers added along the way. Network elements that create packets with no visible transport header -- i.e., those that do encryption or create fragments -- should set the field to NULL. Naturally, firewalls are free to reject such packets. Bellovin [Page 2] White Paper The Shape of the Bits 14 May 1994 It is unclear router-to-host messages should be authenticated. Multicast messages cannot be authenticated without the use of public key techniques; however, those are probably too expensive to use on a routine basis. Unicast messages, such as redirects, could be authenticated using a network layer security protocol; however, that would require a fair amount of extra state per end system in each router. If this were implemented, hosts could randomly challenge routers to repeat recent multicast advertisements using authenticated unicast; a mismatch would would be grounds for sounding an alarm. Address Formats TUBA and CATNIP use CNLP NSAPs for addressing. Particular instantiations of these NSAPs are used for IPv4 addresses. SIPP uses fixed-length 64-bit addresses, with a compatibility-mode bit used to indicate the presence of an IPv4 address. Other combinations of high-order address bits are used to denote particular semantics, such as local addresses. The two essential questions here are whether or not NSAPs (and by extension, CLNP itself) are valuable because of the existing OSI infrastructure, and whether or not the SIPP semantics are valuable. If SIPP semantics are valuable, they can easily be embedded in a TUBA or CATNIP NSAP, possibly by allocation of a new AFI. The SIPP address formats are almost completely untried in the real world. It is thus unclear how valuable they will ultimately turn out to be. On the other hand, they offer the promise of new functionality. Transition SIPP uses a combination of tunneling and packet format translators during transition. CATNIP uses translation and IP options. TUBA requires dual stacks. None are pretty. The translators are a potential bottleneck. Doing the translation is much more expensive than today's routing function. This will be especially serious for large interior routers, which may be servicing many high-speed networks. On the other hand, dual-stack code will require significantly more software development and maintenance into the indefinite future. Both IPv4 and IPng must be supported, with corresponding hooks in the transport protocols. Even some applications will have to know the difference, if they wish to take advantage of new functionality but still behave properly (if suboptimally) when talking to older neighbors. Bellovin [Page 3] White Paper The Shape of the Bits 14 May 1994 Alone of the three proposals, CATNIP is closely tied to its transition strategy. Indeed, that is its raison d'etre. (My apologies for the missing ^...) Both SIPP and TUBA could use the other's transition strategy without significant loss. Oddly enough, I recommend pursuing both. Initial deployments of IPng should be dual stack, to permit interoperability with the vast majority of neighbor systems, and without the need to develop and deploy translator boxes first. As translators become available, support for IPv4 can gradually be dropped as systems are upgraded. The need to talk to the remainder of the IPv4 base can be handled by the translators, which by then should be common. The Shape of the Bits The remaining issue is what the headers should look like. SIPP has the elegance and simplicity of fixed-format headers. TUBA uses CLNP, which is already supported by most routers. It also has variable- length addresses, which, some claim, are inherently slower to parse. That may not be so. Cisco, at least, claims to be able to route OSI at greater than 170K packets/second. To the extent that performance is enhanced by properly-aligned addresses, we can decree a preferred address format, as per TURNIPP. Performance will be better if this format is used, but systems will still work even if it is not. A similar analysis applies to SIPP's nested headers. There is no reason we cannot nest TUBA or CATNIP headers, if we so choose. This would provide fragmentation, source routing, etc. Conclusion We need to agree on the functionality we want. The shape of the bits is almost irrelevant. Bellovin [Page 4] From sob@hsdndev.harvard.edu Sun May 15 00:32:40 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA08586 for ; Sun, 15 May 1994 00:32:54 -0400 Date: Sun, 15 May 94 00:32:40 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405150432.AA19801@hsdndev.harvard.edu> To: deering@parc.xerox.com Subject: Re: DECnet Phase IV to Phase V presentation Cc: ipng@cmf.nrl.navy.mil Steve, Bill gave me a copy so that it could be forwarded to the IPng directorate and to that TACIT WG. I did not ask about wider dist. Can we leave it there for a few days so thedirectorate people can get it than remove it? Jim - can you ask Bill if it would be ok to put it up on hsdndev for full public distribution? Thanks Steve for going through the work, I think there is a bunch of good stuff there. Scott From jcurran@nic.near.net Sun May 15 00:52:42 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA08621 for ; Sun, 15 May 1994 00:53:44 -0400 Received: from platinum.near.net by nic.near.net id aa27397; 15 May 94 0:53 EDT To: Scott Bradner cc: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: DECnet Phase IV to Phase V presentation In-reply-to: Your message of Sun, 15 May 1994 00:32:40 -0400. <9405150432.AA19801@hsdndev.harvard.edu> Date: Sun, 15 May 1994 00:52:42 -0400 From: John Curran Message-ID: <9405150053.aa27397@nic.near.net> -------- ] Thanks Steve for going through the work, I think there is a bunch of ] good stuff there. The last 5 slides are a particularly good summary of some of the lessons learned on how to design effective transition mechanisms. Thanks Scott and Steve! /John From J.Crowcroft@cs.ucl.ac.uk Sun May 15 16:34:44 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA09850 for ; Sun, 15 May 1994 11:35:26 -0400 Message-Id: <199405151535.LAA09850@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 15 May 1994 16:34:46 +0100 To: sob@hsdndev.harvard.edu (Scott Bradner) cc: ipng@cmf.nrl.navy.mil Subject: Re: another white paper In-reply-to: Your message of "Sat, 14 May 94 23:10:21 EDT." <9405150310.AA14303@hsdndev.harvard.edu> Date: Sun, 15 May 94 16:34:44 +0100 From: Jon Crowcroft > The Shape of the Bits very amusing title:-) > The remaining issue is what the headers should look like. SIPP has > the elegance and simplicity of fixed-format headers. TUBA uses CLNP, > which is already supported by most routers. It also has variable- > length addresses, which, some claim, are inherently slower to parse. > That may not be so. Cisco, at least, claims to be able to route OSI > at greater than 170K packets/second. 170k pps is not very fast... also note (sorry to repeat myself), that noone, but noone, supports multicast CLNP. or flows. or, to my knowledge, NLSP that i can use outside the US ... or free host CLNP implementations with any reasoanble testedness. the 'existing code' argument favours none of the proposals (which is nice in a way...i like lvel playing fields!) >Conclusion > We need to agree on the functionality we want. The shape of the bits > is almost irrelevant. i thought the requirements document craig&frank wrote was this jon From jallard@microsoft.com Sun May 15 18:18:57 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA11376 for ; Sun, 15 May 1994 21:23:01 -0400 From: jallard@microsoft.com Received: by netmail2.microsoft.com (5.65/25-eef) id AA27395; Sun, 15 May 94 17:24:34 -0700 Message-Id: <9405160024.AA27395@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sun, 15 May 94 17:24:33 PDT To: ipng@cmf.nrl.navy.mil Subject: Re: concern over retreat..... Date: Sun, 15 May 94 18:18:57 >My second inclination then is to have the experts stay in another >room during the meeting, and be called upon only for the >portions of the meeting that concern their particular expertise. >This would require that they state the expertise they represent >before they come, and they be limited to that. Perhaps it is >impossible to keep them in another room (it is kind of a strange >thing to do), but I think they must somehow be limited in their >discourse to the specific expertise that they represent. i have similar concerns and agree more or less with an approach similar to yours. although i haven't seen a formal agenda, it may make sense to have a directorate-only meeting where we outline our questions and specific concerns, narrow them as much as possible between the members, and only then call in the experts for answers, input, and bribes. we could then kick them out, dileberate further, and repeat the process. i realize that this approach probably sounds a bit lawyer-esque, but i've sat through more mud-slinging sideshows at ietf wg's where work to be done was derailed by finger pointing and breathlessly inspired religious debates between opposing positions. a mechanism similar to what paul has described may be more effective than issuing gag-orders. scott/allison - what are the experts expecting? how were you planning on managing their partipation? _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From kre@munnari.OZ.AU Mon May 16 10:31:57 1994 Return-Path: kre@munnari.OZ.AU Received: from munnari.oz.au (munnari.OZ.AU [128.250.1.21]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA11223 for ; Sun, 15 May 1994 20:33:38 -0400 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24068; Mon, 16 May 1994 10:32:00 +1000 (from kre@munnari.OZ.AU) To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil Subject: Re: continuing EID discussion In-Reply-To: Your message of "Mon, 16 May 1994 08:57:19 +0200." <9405152357.AA15021@cactus.slab.ntt.jp> Date: Mon, 16 May 1994 10:31:57 +1000 Message-Id: <18310.769048317@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-ID: <9405152357.AA15021@cactus.slab.ntt.jp> You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". No, that's not the solution, its a requirement - the reason is that I don't believe that location dependant identifiers can be allocated in an effecient enough manner that we can reasonably allocated a fixed width field of any reasonable size that we can really be sure is going to last forever. Encoding all that location information simply uses too many bits for no useful purpose in the identifier that's required. For this we have to pick something that will last forever without changing format - forever, not just 50 or 100 years. Maybe 128 bit identifiers encoding location might do, but even there I'd be hesitant, as I know how much wastage there is going to be in those things. 256 bits might be enough. I think I'd prefer to make the things location independant, so the allocation policy can be effecient, and we can stick with a reasonably sized field. kre From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:31:57 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA11330 for ; Sun, 15 May 1994 21:11:52 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24495; Mon, 16 May 1994 10:43:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24453; Mon, 16 May 1994 10:33:18 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24068; Mon, 16 May 1994 10:32:00 +1000 (from kre@munnari.OZ.AU) To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil Subject: Re: continuing EID discussion In-Reply-To: Your message of "Mon, 16 May 1994 08:57:19 +0200." <9405152357.AA15021@cactus.slab.ntt.jp> Date: Mon, 16 May 1994 10:31:57 +1000 Message-Id: <18310.769048317@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-ID: <9405152357.AA15021@cactus.slab.ntt.jp> You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". No, that's not the solution, its a requirement - the reason is that I don't believe that location dependant identifiers can be allocated in an effecient enough manner that we can reasonably allocated a fixed width field of any reasonable size that we can really be sure is going to last forever. Encoding all that location information simply uses too many bits for no useful purpose in the identifier that's required. For this we have to pick something that will last forever without changing format - forever, not just 50 or 100 years. Maybe 128 bit identifiers encoding location might do, but even there I'd be hesitant, as I know how much wastage there is going to be in those things. 256 bits might be enough. I think I'd prefer to make the things location independant, so the allocation policy can be effecient, and we can stick with a reasonably sized field. kre From francis@cactus.slab.ntt.jp Mon May 16 08:57:19 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id TAA11090 for ; Sun, 15 May 1994 19:57:59 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 08:57:20 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA04204; Mon, 16 May 1994 08:57:20 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15021; Mon, 16 May 94 08:57:19 JST Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405152357.AA15021@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > > let me say that I hope nobody is still considering the > notion of requiring EIDs for IPng. > > I certainly am. > > As I said before, we should specify requirements, not > solutions. > > EIDs are requirements, not solutions. Or, if the acronym > invokes bad vibes, then the requirement can be stated as ... > > IPng must provide a method to transmit location independant > identifiers for the use of transport protocols, and others, > and the definition the uses of TCP and UCP over IPng must > include using this location independant identifier in their > pseudo-checksums. > > To me, that is requiring EIDs (and one specific use for them). Yes, this is still requiring EIDs, and I still think it doesn't make sense as a requirement. You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". What if you worded it this way: IPng must provide a method to transmit identifiers for the use of higher-layer protocols. The identifier must remain the same throughout the lifetime of the higher-layer protocol, independent of the location of the identified node, and independent of the route used for the packets. This to me is a requirement. I believe that it captures the functionality that you desire without stating that EIDs are the solution. Do you agree? PF > > There's a reason for this - apart from all the other likely > uses of EIDs, defining the transport level to use this > location independant (and hence routing useless) identifier > enables the IP layer to be upgraded much more seamlessly > if (when) needed in the future. > > Pulling one network level header off, doing address (locator) > substitution if needed, and sticking a modified header on > as packets flow from one region of the net to another is a > possibility. What won't be is fiddling TCP to manipulate its > checksum to account for changes in the identifier it uses. > That may be possible now, most of the time, but we have to assume > that in the future at least some packets will either be > encrypted, or signed, above the network level, meaning that > modifications are impossible - modifications at the net level > have to be permitted to allow things like hop counts to be > adjusted, and for manipulation of options, etc. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different > network layers, > > This I agree with. > > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), > > this is a solution, not a requirement, and while I agree with > it as a possibility, I wouldn't require it. > > and 3) is administered by vendors not users (it comes > attached to computers out of the box). > > But this I asbolutely (and totally) disagree with. I require > a mapping from EID into name, that is I want EIDs to be *the* > binary identifier. To make this mapping plausible, there > has to be some kind of administrative relationship between > EIDs owned by some administration (company, department, > individual, whatever), so they can reasonably be made to > fit into the DNS (or any other kind of directory). I do > not require EIDs to be fixed for all time, they only need > remain while any connection using them remains alive - if all > connections die when a host is rebooted, and there is some > way to handle dynamic DNS registration, then assigning a new > (currently unused, not new for all time) EID to a host at boot > time is just fine. > > I have no problem with a vendor assigned ID being used to > acquire the EID from some kind of server, nor, if the > organisation can manage it, to using it with some organisation > prefix to form the EID, but using a vendor assigned number > alone seems unworkable. Using vendor assigned numbers this > way also eases the pressure on them to absolutely guarantee > global uniqueness - their number only needs to be unique within > the organisation in which its used, which means that occasional > errors in id assignment by the vendors can almost certainly be > tolerated - just as we usually tolerate duplicate IEEE assigned > numbers today. > > kre > > Paul's message - if you've seen it before, no need to read > any further.... > > Date: Thu, 12 May 94 10:12:05 JST > From: francis@cactus.slab.ntt.jp (Paul Francis) > Message-Id: <9405120112.AA20949@cactus.slab.ntt.jp> > To: sipp@sunroof.Eng.Sun.COM > Subject: continuing EID discussion (was Re: FORMAL REQUEST : SIPP EIDs and Locators) > > Since the discussion of the Subject Re: FORMAL REQUEST : SIPP EIDs and Locators > has degraded to counting angels and slinging mud, I have stopped reading > it and am concerned that others have also stopped reading it and therefore > didn't look at my reply to Steve and Christian, which I spent a fair amount > of time and thought on. > > So, at the expense of sending the same message to the list twice, I here > resubmit my message under the new Subject..... > > PF > > --------------------------------------------------------------- > > > I want to rebutt the comments of Steve and Christian regarding > the costs/benefits of EIDs. But first let me say that I hope > nobody is still considering the notion of requiring EIDs for > IPng. As I said before, we should specify requirements, not > solutions. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different network layers, > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), and 3) is > administered by vendors not users (it comes attached to > computers out of the box). To make it clear that this is > what I'm talking about, let me call this particular beast > a VANITY (Vendor-Assigned Node-Identifying Transport Yodel). > > (If you're wondering about "Yodel", this is a reference to the > ancient practice of Swiss herders identifying each other by > their distinctive yodel. Yes, I'm making this up..... :-) > > In the following I quote Steve's message. I didn't save > Christian's message, so I'll paraphrase what I remember > him saying. > > > > - EIDs are neither necessary nor sufficient to solve the problems > > for which they are usually cited as a solution, e.g., multi-homing, > > mobility, dynamic address changing. > > This is true except for the case of "serverless" host address > auto-configuration, which I believe to be a very important > requirement, and which I think is the primary benefit of VANITYs. > I think this use alone justifies the use of VANITYs. The other > uses (Steve mentions) are icing on the cake, but I agree with > Steve that these can be done other ways, as shown with SIPP. > > > - EIDs are yet another name space to be allocated and managed, in addition > > to addresses and DNS names. Our experience with our existing name > > spaces makes me *very* loath to create another, especially without a > > *very* concrete reason. > > > > Christian also mentioned the cost of managing "another" name space. > I would like to argue, to the contrary, that the use of VANITYs very > significantly *reduces* the cost of name space management--specifically > because they allow for host auto-configuration. Let's assume that > most of the cost of name space management is human cost. Currently, > hundreds and soon (if not already) thousands of people are involved > in assigning millions of IP host numbers. Further, > those are the people who are the least qualified to be assigning > numbers (not because they aren't smart, but because it isn't their > primary job, they're not networking gurus, etc.). If you use > VANITYs, you move this function to a smallish number of vendors > (some hundreds rather than many thousands), where the assignment > process can be localized, focused, and probably largely automated. > You save countless man-hours. > > >- It may well turn out that higher-level protocols will end up defining > > higher-level IDs at a much finer grain than the EIDs that have been > > proposed in this community, for example, globally unique process IDs > > in support of fine-grain process migration. (See the VMTP protocol > > spec for one example of such an approach.) Such higher-level IDs > > are likely to make EIDs redundant. > > I think this is a wash. Probably a good way for an application to > manage such a number space is to take the network layer identifier > and append some additional information specific to that application. > If the network layer identifier is an address (i.e., combination > locator/identifier), then the address also is "redundant". Either way, > you are replicating some information. However, if you believe > VANITYs to be stable for longer than addresses, perhaps the use of > VANITYs to help manage the application EIDs is better than the > use of addresses. > > > >- In the most common case, where the locating semantics of either or both > ............ > > of changing addresses, or whatever), requiring the presence of pure > > EIDs would make the packet header significantly larger than it would > > otherwise be. True, the price we accept for our connectionless internet > > Agreed. > > > model is a large header on every packet. But I think we have a duty as > > designers to make relatively efficient use of that header space, since > > it is a "tax" imposed on every packet. I am particularly concerned > > I agree. If all other things are equal, we should favor smaller > headers.....but...... > > > about header size because I see increasing use of encapsulation as a > > multi-purpose mechanism in the Internet, such that many packets may > > end up carrying multiple SIPP headers on at least some part of their > > At least some of the reasons for such encapsulations would be eliminated > if we had VANITYs (for instance, the use of encapsulation for getting > mobility). > > > journey. I'm also concerned with making it possible to forward SIPP > > packets at very high speed, and keeping the basic header size relatively > > compact is one part of that (e.g., more likely to fit into a cache line, > > when using a general-purpose processor as a packet switch). > > Mumble. Maybe so. The use of VANITYs doesn't increase the amount > of info that has to be examined, though, so perhaps with some care > one can manage to funnel only the needed info into the cache line. > I don't know for sure, and it probably differs significantly from > machine to machine. Another point is that the VANITY might help > high speed switching because it can be used as a flow ID, blah blah > mumble hand wave. > > > A common answer to the large header size issue is to suggest using > > header compression over slow links. Besides the fact that that > > does not address the high-speed forwarding issue, another problem > > is that our current strategy for header compression in IPv4 only works > > for TCP traffic and relies on certain properties of TCP. However, I > > expect much of the high-volume traffic in the future to be UDP, e.g., > > What? High volume over slow links? If you can solve that one you > can become a rich man! :-) > > If it is high volume (and therefore high speed), you by definition > don't need header compression. > > > real-time audio and video. I don't know what's involved in building > > a robust header compression scheme for SIPP/UDP headers (there's a > > good project for someone to work on!), but I'd rather not depend on > > I agree. In fact, SIPP could use this like yesterday.... > > > it being easy or cheap to do. Another, perhaps unfounded, concern is > > that compression spends CPU cycles to save bandwidth, but we may want > > to support nodes that are starved for *both* CPU and bandwidth, e.g., > > very low-powered wireless devices. > > I suspect that a machine that is starved for CPU and bandwith will > not be exchanging packets simultaneously with a large number of other > devices, and therefore compression should work well at low cost > (i.e., lots of redundancy from packet to packet). > > > Ok, finally I want to address Christian's comments (and Minshall has > also mentioned this) about the non-uniqueness of IEEE 802 numbers. > I agree that this is a problem, but I wonder how much. In the > context of SIPP, the spec is very specific about requiring the use > of "universally administered" 802 numbers. Thus, I *hope* that > the "soft" assignments of 802 numbers doesn't apply. As for sloppy > practice by vendors resulting in duplicate "universally administered" > 802 numbers, at least with SIPP this should rarely cause a real > problem (unless I'm missing something). *If* we get SIPP hosts to > *always* assign a different flow ID for each route sequence it is > using, then duplicate 802 numbers only cause a problem when > 1) the hosts with the duplicates are talking to the same machine, > 2) the flow IDs are the same, and 3) the other identifiers, such > as transport socket, are all the same. I think that the probability > of this is small enough that failures caused for this reason will > be in the noise compared to failures caused for other reasons. > > /* start aside */ > > As an aside, this is *yet another* good reason to have > hosts always assign a flow ID. I'm now thoroughly > convinced that the cost of doing this is well worth it. > Off the top of my head, the benefits are: > > 1. Hosts receiving packets can use the flow ID to > detect a change in route sequence. Thus, they > don't have to parse through the route sequence > every time. > > 2. Routers can use the flow ID to identify flows. > My gut feeling is that 90% or more of real time > could be handled without explicit flow setup. > > 3. If not 2, then at least routers can use it to > aid their caching strategies (I know that there > are other issues here, like how to advance ther > route header). > > 4. "Fixes" the blatant distant-snooping security hole > introduced by route sequence reversal. (Sorry Ran, > but having thought about this more, I remain > convinced that this technique is useful for this > purpose.) > > 5. The duplicate VANITY problem. > > /* end aside */ > > > Actually, this notion that a host can successfully talk to > multiple other hosts that have the same VANITY is interesting > to me (not that I'm advocating it). Specifically, it makes > me ask what the point is to IP header authentications, especially > in the absense of higher-layer authentication. As long as > packets can successfully get from source to dest and back, what > does the network layer care about authentication? The application > cares about authentication, but authenticating the network layer > for the purpose of authenticating the application seems weak > and more expensive than doing it at the application. > > Maybe I'm just being dense, but can someone please re-iterate > for me why we need to authenticate at the network layer? > > PF > > From owner-Big-Internet@munnari.OZ.AU Mon May 16 08:57:19 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA11310 for ; Sun, 15 May 1994 21:06:44 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24440; Mon, 16 May 1994 10:27:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24374; Mon, 16 May 1994 10:07:23 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22845; Mon, 16 May 1994 09:57:30 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 08:57:20 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA04204; Mon, 16 May 1994 08:57:20 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15021; Mon, 16 May 94 08:57:19 JST Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405152357.AA15021@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > > let me say that I hope nobody is still considering the > notion of requiring EIDs for IPng. > > I certainly am. > > As I said before, we should specify requirements, not > solutions. > > EIDs are requirements, not solutions. Or, if the acronym > invokes bad vibes, then the requirement can be stated as ... > > IPng must provide a method to transmit location independant > identifiers for the use of transport protocols, and others, > and the definition the uses of TCP and UCP over IPng must > include using this location independant identifier in their > pseudo-checksums. > > To me, that is requiring EIDs (and one specific use for them). Yes, this is still requiring EIDs, and I still think it doesn't make sense as a requirement. You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". What if you worded it this way: IPng must provide a method to transmit identifiers for the use of higher-layer protocols. The identifier must remain the same throughout the lifetime of the higher-layer protocol, independent of the location of the identified node, and independent of the route used for the packets. This to me is a requirement. I believe that it captures the functionality that you desire without stating that EIDs are the solution. Do you agree? PF > > There's a reason for this - apart from all the other likely > uses of EIDs, defining the transport level to use this > location independant (and hence routing useless) identifier > enables the IP layer to be upgraded much more seamlessly > if (when) needed in the future. > > Pulling one network level header off, doing address (locator) > substitution if needed, and sticking a modified header on > as packets flow from one region of the net to another is a > possibility. What won't be is fiddling TCP to manipulate its > checksum to account for changes in the identifier it uses. > That may be possible now, most of the time, but we have to assume > that in the future at least some packets will either be > encrypted, or signed, above the network level, meaning that > modifications are impossible - modifications at the net level > have to be permitted to allow things like hop counts to be > adjusted, and for manipulation of options, etc. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different > network layers, > > This I agree with. > > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), > > this is a solution, not a requirement, and while I agree with > it as a possibility, I wouldn't require it. > > and 3) is administered by vendors not users (it comes > attached to computers out of the box). > > But this I asbolutely (and totally) disagree with. I require > a mapping from EID into name, that is I want EIDs to be *the* > binary identifier. To make this mapping plausible, there > has to be some kind of administrative relationship between > EIDs owned by some administration (company, department, > individual, whatever), so they can reasonably be made to > fit into the DNS (or any other kind of directory). I do > not require EIDs to be fixed for all time, they only need > remain while any connection using them remains alive - if all > connections die when a host is rebooted, and there is some > way to handle dynamic DNS registration, then assigning a new > (currently unused, not new for all time) EID to a host at boot > time is just fine. > > I have no problem with a vendor assigned ID being used to > acquire the EID from some kind of server, nor, if the > organisation can manage it, to using it with some organisation > prefix to form the EID, but using a vendor assigned number > alone seems unworkable. Using vendor assigned numbers this > way also eases the pressure on them to absolutely guarantee > global uniqueness - their number only needs to be unique within > the organisation in which its used, which means that occasional > errors in id assignment by the vendors can almost certainly be > tolerated - just as we usually tolerate duplicate IEEE assigned > numbers today. > > kre > > Paul's message - if you've seen it before, no need to read > any further.... > > Date: Thu, 12 May 94 10:12:05 JST > From: francis@cactus.slab.ntt.jp (Paul Francis) > Message-Id: <9405120112.AA20949@cactus.slab.ntt.jp> > To: sipp@sunroof.Eng.Sun.COM > Subject: continuing EID discussion (was Re: FORMAL REQUEST : SIPP EIDs and Locators) > > Since the discussion of the Subject Re: FORMAL REQUEST : SIPP EIDs and Locators > has degraded to counting angels and slinging mud, I have stopped reading > it and am concerned that others have also stopped reading it and therefore > didn't look at my reply to Steve and Christian, which I spent a fair amount > of time and thought on. > > So, at the expense of sending the same message to the list twice, I here > resubmit my message under the new Subject..... > > PF > > --------------------------------------------------------------- > > > I want to rebutt the comments of Steve and Christian regarding > the costs/benefits of EIDs. But first let me say that I hope > nobody is still considering the notion of requiring EIDs for > IPng. As I said before, we should specify requirements, not > solutions. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different network layers, > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), and 3) is > administered by vendors not users (it comes attached to > computers out of the box). To make it clear that this is > what I'm talking about, let me call this particular beast > a VANITY (Vendor-Assigned Node-Identifying Transport Yodel). > > (If you're wondering about "Yodel", this is a reference to the > ancient practice of Swiss herders identifying each other by > their distinctive yodel. Yes, I'm making this up..... :-) > > In the following I quote Steve's message. I didn't save > Christian's message, so I'll paraphrase what I remember > him saying. > > > > - EIDs are neither necessary nor sufficient to solve the problems > > for which they are usually cited as a solution, e.g., multi-homing, > > mobility, dynamic address changing. > > This is true except for the case of "serverless" host address > auto-configuration, which I believe to be a very important > requirement, and which I think is the primary benefit of VANITYs. > I think this use alone justifies the use of VANITYs. The other > uses (Steve mentions) are icing on the cake, but I agree with > Steve that these can be done other ways, as shown with SIPP. > > > - EIDs are yet another name space to be allocated and managed, in addition > > to addresses and DNS names. Our experience with our existing name > > spaces makes me *very* loath to create another, especially without a > > *very* concrete reason. > > > > Christian also mentioned the cost of managing "another" name space. > I would like to argue, to the contrary, that the use of VANITYs very > significantly *reduces* the cost of name space management--specifically > because they allow for host auto-configuration. Let's assume that > most of the cost of name space management is human cost. Currently, > hundreds and soon (if not already) thousands of people are involved > in assigning millions of IP host numbers. Further, > those are the people who are the least qualified to be assigning > numbers (not because they aren't smart, but because it isn't their > primary job, they're not networking gurus, etc.). If you use > VANITYs, you move this function to a smallish number of vendors > (some hundreds rather than many thousands), where the assignment > process can be localized, focused, and probably largely automated. > You save countless man-hours. > > >- It may well turn out that higher-level protocols will end up defining > > higher-level IDs at a much finer grain than the EIDs that have been > > proposed in this community, for example, globally unique process IDs > > in support of fine-grain process migration. (See the VMTP protocol > > spec for one example of such an approach.) Such higher-level IDs > > are likely to make EIDs redundant. > > I think this is a wash. Probably a good way for an application to > manage such a number space is to take the network layer identifier > and append some additional information specific to that application. > If the network layer identifier is an address (i.e., combination > locator/identifier), then the address also is "redundant". Either way, > you are replicating some information. However, if you believe > VANITYs to be stable for longer than addresses, perhaps the use of > VANITYs to help manage the application EIDs is better than the > use of addresses. > > > >- In the most common case, where the locating semantics of either or both > ............ > > of changing addresses, or whatever), requiring the presence of pure > > EIDs would make the packet header significantly larger than it would > > otherwise be. True, the price we accept for our connectionless internet > > Agreed. > > > model is a large header on every packet. But I think we have a duty as > > designers to make relatively efficient use of that header space, since > > it is a "tax" imposed on every packet. I am particularly concerned > > I agree. If all other things are equal, we should favor smaller > headers.....but...... > > > about header size because I see increasing use of encapsulation as a > > multi-purpose mechanism in the Internet, such that many packets may > > end up carrying multiple SIPP headers on at least some part of their > > At least some of the reasons for such encapsulations would be eliminated > if we had VANITYs (for instance, the use of encapsulation for getting > mobility). > > > journey. I'm also concerned with making it possible to forward SIPP > > packets at very high speed, and keeping the basic header size relatively > > compact is one part of that (e.g., more likely to fit into a cache line, > > when using a general-purpose processor as a packet switch). > > Mumble. Maybe so. The use of VANITYs doesn't increase the amount > of info that has to be examined, though, so perhaps with some care > one can manage to funnel only the needed info into the cache line. > I don't know for sure, and it probably differs significantly from > machine to machine. Another point is that the VANITY might help > high speed switching because it can be used as a flow ID, blah blah > mumble hand wave. > > > A common answer to the large header size issue is to suggest using > > header compression over slow links. Besides the fact that that > > does not address the high-speed forwarding issue, another problem > > is that our current strategy for header compression in IPv4 only works > > for TCP traffic and relies on certain properties of TCP. However, I > > expect much of the high-volume traffic in the future to be UDP, e.g., > > What? High volume over slow links? If you can solve that one you > can become a rich man! :-) > > If it is high volume (and therefore high speed), you by definition > don't need header compression. > > > real-time audio and video. I don't know what's involved in building > > a robust header compression scheme for SIPP/UDP headers (there's a > > good project for someone to work on!), but I'd rather not depend on > > I agree. In fact, SIPP could use this like yesterday.... > > > it being easy or cheap to do. Another, perhaps unfounded, concern is > > that compression spends CPU cycles to save bandwidth, but we may want > > to support nodes that are starved for *both* CPU and bandwidth, e.g., > > very low-powered wireless devices. > > I suspect that a machine that is starved for CPU and bandwith will > not be exchanging packets simultaneously with a large number of other > devices, and therefore compression should work well at low cost > (i.e., lots of redundancy from packet to packet). > > > Ok, finally I want to address Christian's comments (and Minshall has > also mentioned this) about the non-uniqueness of IEEE 802 numbers. > I agree that this is a problem, but I wonder how much. In the > context of SIPP, the spec is very specific about requiring the use > of "universally administered" 802 numbers. Thus, I *hope* that > the "soft" assignments of 802 numbers doesn't apply. As for sloppy > practice by vendors resulting in duplicate "universally administered" > 802 numbers, at least with SIPP this should rarely cause a real > problem (unless I'm missing something). *If* we get SIPP hosts to > *always* assign a different flow ID for each route sequence it is > using, then duplicate 802 numbers only cause a problem when > 1) the hosts with the duplicates are talking to the same machine, > 2) the flow IDs are the same, and 3) the other identifiers, such > as transport socket, are all the same. I think that the probability > of this is small enough that failures caused for this reason will > be in the noise compared to failures caused for other reasons. > > /* start aside */ > > As an aside, this is *yet another* good reason to have > hosts always assign a flow ID. I'm now thoroughly > convinced that the cost of doing this is well worth it. > Off the top of my head, the benefits are: > > 1. Hosts receiving packets can use the flow ID to > detect a change in route sequence. Thus, they > don't have to parse through the route sequence > every time. > > 2. Routers can use the flow ID to identify flows. > My gut feeling is that 90% or more of real time > could be handled without explicit flow setup. > > 3. If not 2, then at least routers can use it to > aid their caching strategies (I know that there > are other issues here, like how to advance ther > route header). > > 4. "Fixes" the blatant distant-snooping security hole > introduced by route sequence reversal. (Sorry Ran, > but having thought about this more, I remain > convinced that this technique is useful for this > purpose.) > > 5. The duplicate VANITY problem. > > /* end aside */ > > > Actually, this notion that a host can successfully talk to > multiple other hosts that have the same VANITY is interesting > to me (not that I'm advocating it). Specifically, it makes > me ask what the point is to IP header authentications, especially > in the absense of higher-layer authentication. As long as > packets can successfully get from source to dest and back, what > does the network layer care about authentication? The application > cares about authentication, but authenticating the network layer > for the purpose of authenticating the application seems weak > and more expensive than doing it at the application. > > Maybe I'm just being dense, but can someone please re-iterate > for me why we need to authenticate at the network layer? > > PF > > From francis@cactus.slab.ntt.jp Mon May 16 09:44:58 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id UAA11243 for ; Sun, 15 May 1994 20:45:02 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 09:44:59 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA04620; Mon, 16 May 1994 09:44:59 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15601; Mon, 16 May 94 09:44:58 JST Date: Mon, 16 May 94 09:44:58 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160044.AA15601@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil Subject: concern over retreat..... I am becoming increasingly concerned (upset actually) about the participation of non-directorate member invitees at the meeting. I was initially under the impression that they would be coming only as "experts", and thus (I assumed) their input would naturally be limited to what they are experts on--primarily the documents that they authored. It seems to me, however, that they are being expected to participate practically as full-fledged members of the Directorate. I think there was a message at one point that they would be expected to be familier with the various proposals and white papers. I am also familier with one case where an invited person was asked to give presentations on existing protocols (IPX, Appletalk) that he is not generally familier with. I have so far been impressed with the generally non-partisan participation of the members. I was looking forward to more of the same in Chicago. In addition, I think that the current group has managed to develop something of a rapport. Now, however, I am losing faith that we can have anything other than a "my-protocol-is-better-than-yours" show-down. My inclination at this point is to un-invite all of the invited experts except perhaps one TUBA expert. I agree that TUBA is under-represented compared to SIPP, since SIPP has both Steve and I, and TUBA has only Mark (as far as I know....I don't have a list of the membership, but I can't think of another TUBA principal on the Directorate....in any event, I remember Mark saying that he felt TUBA was under-represented, so......). However, it is unfair to the invitees that they be un-invited now, so perhaps that is not an option. My second inclination then is to have the experts stay in another room during the meeting, and be called upon only for the portions of the meeting that concern their particular expertise. This would require that they state the expertise they represent before they come, and they be limited to that. Perhaps it is impossible to keep them in another room (it is kind of a strange thing to do), but I think they must somehow be limited in their discourse to the specific expertise that they represent. Comments? PF From francis@cactus.slab.ntt.jp Mon May 16 10:03:22 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA11295 for ; Sun, 15 May 1994 21:05:17 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 10:03:23 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA04877; Mon, 16 May 1994 10:03:23 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15986; Mon, 16 May 94 10:03:22 JST Date: Mon, 16 May 94 10:03:22 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160103.AA15986@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > You are assuming the solution in the above "requirement", > that is, you are assuming a "location independant identifier". > > No, that's not the solution, its a requirement - the reason is > that I don't believe that location dependant identifiers can > be allocated in an effecient enough manner that we can > reasonably allocated a fixed width field of any reasonable > size that we can really be sure is going to last forever. Ok, then add the requirement that said identifier must be less than or equal to whatever number you find appropriate, say 64 bits? Well, even that is specifying a solution. A real requiement would say something like "the identifier must be parsable by a current state of the art computer in xx micro-seconds). Blah. PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:03:22 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id AAA11862 for ; Mon, 16 May 1994 00:06:51 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA24770; Mon, 16 May 1994 13:21:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA24761; Mon, 16 May 1994 13:20:49 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25353; Mon, 16 May 1994 11:04:12 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 10:03:23 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA04877; Mon, 16 May 1994 10:03:23 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15986; Mon, 16 May 94 10:03:22 JST Date: Mon, 16 May 94 10:03:22 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160103.AA15986@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > You are assuming the solution in the above "requirement", > that is, you are assuming a "location independant identifier". > > No, that's not the solution, its a requirement - the reason is > that I don't believe that location dependant identifiers can > be allocated in an effecient enough manner that we can > reasonably allocated a fixed width field of any reasonable > size that we can really be sure is going to last forever. Ok, then add the requirement that said identifier must be less than or equal to whatever number you find appropriate, say 64 bits? Well, even that is specifying a solution. A real requiement would say something like "the identifier must be parsable by a current state of the art computer in xx micro-seconds). Blah. PF From sob@hsdndev.harvard.edu Mon May 16 07:00:12 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA12849 for ; Mon, 16 May 1994 07:00:19 -0400 Date: Mon, 16 May 94 07:00:12 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405161100.AA19484@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: poke We have not yet received proposal reviews from most of you. Since we need to have these reviews to finalize the detailed agenda for the retreat, we would like it if you could get the reviews to us asap. Scott & Allison From craig@aland.bbn.com Mon May 16 09:20:29 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA14719 for ; Mon, 16 May 1994 12:22:38 -0400 Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA14129 for ipng@cmf.nrl.navy.mil; Mon, 16 May 94 12:22:27 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA06706; Mon, 16 May 1994 09:20:30 -0700 Message-Id: <199405161620.JAA06706@aland.bbn.com> To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: ipng@cmf.nrl.navy.mil Subject: Re: concern over retreat..... In-Reply-To: Your message of Mon, 16 May 94 09:44:58 +0200. <9405160044.AA15601@cactus.slab.ntt.jp> From: Craig Partridge Date: Mon, 16 May 94 09:20:29 -0700 Sender: craig@aland.bbn.com Paul: I seem to be a quasi-IPng directorate member by virtue of working on the requirements document but I'm not going to be in Chicago (so I may have some tiny objectivity). You raise a good point. When I was on the IETF Nominating Committee in 1993, we eventually adopted a practice of holding some meetings which excluded the ex-officio members -- in part because of situations where ex-officio members would start saying that they didn't like the nom com's decisions and wouldn't support them in public. (We had some reaction that if one wasn't willing to be on the firing line, even for the parts one didn't like, one should be in the meeting making decisions). My point is largely that if you expect the Chicago meeting to go over difficult topics, your additional members may harm group decision making (in part, because they don't identify with the group). Craig From brian@dxcoms.cern.ch Mon May 16 18:32:20 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA14809 for ; Mon, 16 May 1994 12:32:55 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29409; Mon, 16 May 1994 18:32:21 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05001; Mon, 16 May 1994 18:32:20 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405161632.AA05001@dxcoms.cern.ch> Subject: Re: concern over retreat..... To: ipng@cmf.nrl.navy.mil Date: Mon, 16 May 1994 18:32:20 +0200 (MET DST) In-Reply-To: <199405161620.JAA06706@aland.bbn.com> from "Craig Partridge" at May 16, 94 09:20:29 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 456 I think it is essential that at least one session this week is IPng Directorate members ONLY where people can really say what they think. It might even be best to ask the proposal chairs to withdraw from that session. If there is no such session, the results will be suspect. Wish I could be there with you to thump on the table about this. Brian (totally zonked by the big-i list: we need to stop going over the same ground every four months or so.) From bound@zk3.dec.com Tue May 17 00:37:30 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA19133 for ; Tue, 17 May 1994 00:40:11 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA20165; Mon, 16 May 94 21:37:38 -0700 Received: by xirtlu.zk3.dec.com; id AA05382; Tue, 17 May 1994 00:37:36 -0400 Message-Id: <9405170437.AA05382@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Regrets on the Retreat Date: Tue, 17 May 94 00:37:30 -0400 X-Mts: smtp Fellow Directorate, Unfortuneately due to business and personal reasons I cannot travel to the retreat at this time. I spoke with both Allison and Scott. I can be available for teleconference as its possible. Sincerely, /jim From francis@cactus.slab.ntt.jp Tue May 17 10:24:12 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA18340 for ; Mon, 16 May 1994 21:24:22 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 17 May 1994 10:24:13 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA26518; Tue, 17 May 1994 10:24:13 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA28968; Tue, 17 May 94 10:24:12 JST Date: Tue, 17 May 94 10:24:12 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405170124.AA28968@cactus.slab.ntt.jp> To: brian@dxcoms.cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: concern over retreat..... > > I think it is essential that at least one session this week > is IPng Directorate members ONLY where people can really say > what they think. It might even be best to ask the proposal I think perhaps the first agenda item should be how to deal with the invited guests--and that this item should be discussed without invited guests present. > chairs to withdraw from that session. If there is no such > session, the results will be suspect. Wish I could be there > with you to thump on the table about this. > This is a reasonable idea. Much as I'd like to, and try, I don't think I can ever completely take my SIPP hat off.... >From my so-far-limited-experience, the trans-pacific jet lag hits hard at about 2:00 PM, so even if I don't leave the room, any discussion that takes place at that time may in effect be in my absense..... :-) PF From Greg_Minshall@Novell.COM Tue May 17 14:58:38 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA26153 for ; Tue, 17 May 1994 18:03:11 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18636; Tue, 17 May 94 16:06:13 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06587; Tue, 17 May 94 14:58:38 PDT Date: Tue, 17 May 94 14:58:38 PDT Message-Id: <9405172158.AB06587@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jon Crowcroft From: Greg Minshall Subject: Re: IPng Architecure and an IPng Architect Cc: ipng@cmf.nrl.navy.mil Jon, >I believe we have all the pieces of an architecture, but perhaps i >have perceived them as a whole, where maybe i'm either wrong, or else >that perception is hard when yo uare closer to the IETF than me. I think we have pieces, some more mature, some less mature. But, i don't think we have a consistent vision (at least, with reference to Steve D's musings, more than the vision of IPv4). >Personally, I belive dual stack is unacceptable for financial reasons, >unless someone can show me why interworking is more expesnive, and >given our expierence of interworking colouirred book, ISO and IPv4, i >doubt they will. All proposals are, to me, ultimately dual stack. SIPP has the transport and even the application wondering "is it real, or is it IPv4?". Greg From Greg_Minshall@Novell.COM Tue May 17 14:58:38 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA26153 for ; Tue, 17 May 1994 18:03:11 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18636; Tue, 17 May 94 16:06:13 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06587; Tue, 17 May 94 14:58:38 PDT Date: Tue, 17 May 94 14:58:38 PDT Message-Id: <9405172158.AB06587@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jon Crowcroft From: Greg Minshall Subject: Re: IPng Architecure and an IPng Architect Cc: ipng@cmf.nrl.navy.mil Status: O Jon, >I believe we have all the pieces of an architecture, but perhaps i >have perceived them as a whole, where maybe i'm either wrong, or else >that perception is hard when yo uare closer to the IETF than me. I think we have pieces, some more mature, some less mature. But, i don't think we have a consistent vision (at least, with reference to Steve D's musings, more than the vision of IPv4). >Personally, I belive dual stack is unacceptable for financial reasons, >unless someone can show me why interworking is more expesnive, and >given our expierence of interworking colouirred book, ISO and IPv4, i >doubt they will. All proposals are, to me, ultimately dual stack. SIPP has the transport and even the application wondering "is it real, or is it IPv4?". Greg From bound@zk3.dec.com Wed May 18 10:34:57 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA00366 for ; Wed, 18 May 1994 10:47:03 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA15118; Wed, 18 May 94 07:35:07 -0700 Received: by xirtlu.zk3.dec.com; id AA08096; Wed, 18 May 1994 10:35:03 -0400 Message-Id: <9405181435.AA08096@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IEEE Addresses as Unique from SIPP List Date: Wed, 18 May 94 10:34:57 -0400 X-Mts: smtp If your not on the SIPP list this just got sent out. We need to be careful if we assume IEEE 802 MAC anything. This corresponds with my intelligence on this subject too. /jim ------- Forwarded Message Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from decvax.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA03898; Wed, 18 May 1994 10:27:13 -0400 Received: from murtoa.cs.mu.OZ.AU by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16557; Wed, 18 May 1994 10:27:05 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA02522; Wed, 18 May 1994 23:44:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA02513; Wed, 18 May 1994 23:35:47 +1000 Received: from xap.xyplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26382; Thu, 19 May 1994 00:04:06 +1000 (from milan@mjm.xyplex.com) Received: from mjm.xyplex.com by xap.xyplex.com id ; Wed, 18 May 94 09:49:01 -0500 Received: by xyplex.com (4.1/SMI-4.1) id AA22825; Wed, 18 May 94 10:05:32 EDT Date: Wed, 18 May 94 10:05:32 EDT From: milan@mjm.xyplex.com (Milan Merhar) Message-Id: <9405181405.AA22825@xyplex.com> To: big-internet@munnari.OZ.AU In-Reply-To: Greg Minshall's message of Tue, 17 May 94 14:12:35 PDT <9405172112.AA06513@WC.Novell.COM> Subject: IEEE 802 not unique enough??? Sad to say, IEEE 802 addresses, even if obtained from an "official" source, can't be considered "globally" unique if the possibility exists that an organization's network may be attached in multiple places to the external network. The current practice of some vendors is to use the same 802 address on each interface of multi-interface devices, on the theory that they are attached to "different networks" and therefore isolated. If these networks should find themselves attached to the same external realm, the duplicated addresses may both be visible to an external observer. This is of course a common issue with DECnet routers, which use the same "locally administered" address on each interface. Lately, I've heard of devices that do the same thing but with "globally administered" (i.e. second bit cleared) 802 addresses. A similar condition may occur during flooding with any MAC-layer bridge. It will propagate all the MAC addresses from "over there" to appear to be "over here". This is good, unless (again) there is some observer that can see both networks at the same time. So, how many added bits are need to make 802 addresses acceptable? What implementation rules are necessary to insure that they remain unique? (In other words, how do we define "unique"?) Can we set up the necessary (probably hierachical) prefix assignment mechanism without setting ourselves up for another round of "running out of addresses" in the future? By the way, I understand from some folks that are IEEE regulars that they have a defacto prohibition on any scheme that requires the creation and management of ANOTHER set of globally unique numbers; one is enough trouble to manage for them, I guess... Milan J. Merhar, Xyplex, Inc. 295 Foster St. Littleton, MA 01460 USA Internet: milan@xyplex.com Phone:(508)952-4713 Fax:(508)952-4887 ------- End of Forwarded Message From sob@hsdndev.harvard.edu Thu May 19 08:15:55 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA05672 for ; Thu, 19 May 1994 08:16:09 -0400 Date: Thu, 19 May 94 08:15:55 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405191215.AA22031@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: nsap paper >From skh@merit.edu Thu May 19 01:41:38 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA03972; Thu, 19 May 1994 01:44:17 -0400 Received: (skh@localhost) by merit.edu (8.6.8.1/merit-1.0) id BAA15175; Thu, 19 May 1994 01:40:45 -0400 Date: Thu, 19 May 1994 01:40:45 -0400 From: Susan Hares Message-Id: <199405190540.BAA15175@merit.edu> To: sob@harvard.edu Subject: NSAP paper for Retreat Cc: peter@goshawk.lanl.gov, skh@merit.edu, yakov@watson.ibm.com Status: R Scott: Yakov and Peter assure me that you'd like to have more information on NSAPs. I've written up this RFC for FYI track for Tuba area. It will be posted after a few more days of review. Please consider it still a very rough draft. However, it seems timely for your retreat. I also owe Allison at least one paper due to our last discussion at IETF. I stayed up late to finish it, but I'm called home to a sick child. Allison will chuckle. If this is too informal, oh well.. some of us you just can't train at all. My best wishes to you-all, Sue Hares ---- Network Working Group Susan Hares Request for Comments: DRAFT Merit/NSFNET May 1994 NSAP Usage Status of this memo This memo provides information on the benefits of ISO NSAP (Network Server Access Point) address as part of the IP Next Generation protocol. The purpose of this document is informational, and will be guided along the Information RFC track. 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." 1. Overview Network Service Access Points (NSAPs) [1] provide an existing network address space with distributed address administration that provides substantial technical benefits. This memo describes the technical benefits, and provides an overview of the distributed administration of the this addresses. For an IP Next Generation addresses to aid the growth of the Internet, the address space must be easy to administer. Two types of administration will aid the Internet: - easy administration for local, special or limited area networks, and - a continuation of the fine work the Internet Address Naming and Authority (IANA) and Routing Registration Authorities to assign and administer network address assignments. The NSAP address space administration allows both types of administration of assignment of addresses. In addition to assignment addresses, those networks attaching to the Public Internet should be easy to add to routing registrations that aid network operations. The RIPE document "CLNS routing-domain object for the RIPE database" [2] provides an example of one approach that type of registration that uses NSAP addresses. Since ISO routing policy, address assignment, and route aggregation is analogous to Classless Inter- Domain Routing (CIDR) [3] [4][5], the RIPE CLNS document aligns the ISO information kept with the IP CIDR information. The benefit of this approach is that tools developed for use with the RIPE registry for IP CIDR routes may be used ISO CLNS routes. This easy migration path to Tuba IP next generation solution eases some operational issues regarding transition to the IP next generation solution. 2. Technical benefits of NSAP address NSAP addresses provide: 1) Mechanism embed a Unique System ID while still allowing Routing by shortest prefix 2) Easily obtainable local area NSAP addresses 3) Embedded subnet Addresses 4) Routing by Prefixes The Internet can obtain a large address space from ISO and assign and administer space. The NSAP address administration philosophy is to distribute the administration of the addresses. The IANA (Internet Address Naming Authority) and it's distributed European, US or Asian Routing Registration authorities could continue the mechanism for assignment of NSAP addresses as they do for IP version 4 addresses. Today the IANA delegates blocks of addresses to regional authorities such as Europe or Asian groups for assignment. As the Internet grows, it may be in the best interest of the Internet to further distribute the registration of routing addresses and information. This distribution of assignment is in the best philosophy of both the ISO addressing authorities and the IANA. Perhaps this is philosophy is common because it is the only workable plan to handle growth and to encourage up to date and accurate information that will be used. 2.1 Mechanism embed a Unique System ID while still allowing Routing by shortest prefix In the list of IP next generation desires is the desire for a unique system ID per machine. This unique system ID would be attached to each box and allow a machine to be uniquely identified. This unique identification (with no topological significance) may have many uses, such as auto-configuration of addresses or identification in mobile addressing schemes. While it is possible to have autoconfiguration schemes without unique IDs, the autoconfiguration schemes without unique ID involve either extra boxes (to hand out addresses), or involve reuse of addresses (like Appletalk). Since addresses are likely to be cached, reuse of addresses can create confusion with misdelivered packets. Whether this unique system id be 6 bytes or 8 bytes or 10 bytes, or some other length the NSAP address can encompass these systems IDs, and allow additional fields to use as network prefixes. Network prefixes, are defined in this paper to mean those bits in an address that allow the system to be associated with a network. In the CIDR world, this might be 128.2.1/24 prefix (128.2.1 prefix 24 bits in length.) With NSAP addresses this might be 39.840f.80ff.ff00/40 (length of 40 bits). [For explanation on the NSAP dot address format, see reference [6].] The network prefix portion of the NSAP address that comes before these system ID bytes allows the address to be part of larger address plan. Careful assignment of these network prefixes allows for the aggregation of network addresses reachable via a Network Service provider such as NEARNet or in a portion of the world such as Japan or Europe. For example, combining all 193.x.x.x address into one aggregation would greatly reduce routing tables. The aggregation reduces the necessary routing information that a router must hold, or routing protocols must pass. In the ISO 8348/Addendum 2 [1] includes the following addressing plans to choose address formats from: X.121 - 14 digits circuits ISO DCC - country code base F.69 - Telex numbers E.163 - Public Switched Telephone network numbers E.164 - ISDN number of up to 15 digits ISO ICD - International Code Designator Local - Locally defined Address formats. Evident from this list is fact ISO has registered addressing authorities for address formats with different level of technology across the span of many years. To assign to IP Version 7 as another addressing plan, would fit naturally into the ISO philosophy. In addition, the NSAP plans assigns address space for those who want local or private networks. Two of these addressing formats, ISO DCC or Country and ISO ICD used in the early internet CLNS experiments. These two formats have similar 20 octet formats which provides one method of assignment to encourage address assignment that will benefit from aggregation. Examples of these two 20 byte octets are included below, but should be viewed as just a first "guess" at how to do address assignment so we can aggregate large blocks of address. With the advent of CIDR in the Internet, the bright minds that keep our Internet functioning will probably figure out a better way to handle address assignment. A possible IP version 7 NSAP assignment is provided. This example is not the author's or anyone's favorite, it just provides an example of the flexibility of NSAPs. The final examples shows a simple private NSAP network that will never be attached to the public internet with several internal subnet networks. =================================================================== | bytes | | 1 | 2-3 | 4 | 5-7 | 8-9 | 10-11 |12-13| 14-19 | 20 | ------------------------------------------------------------------- | DCC code -ANSI US | |AFI| CC | ver | AAI | resv | RD |Area | System id |Selector| |39 | 840f | 80 |F8000 | 0000 | 0001 |0001 |010203040506|tcp port| ------------------------------------------------------------------- | ICD code - GOSIP | |AFI| ID | ver | AAI | resv | RD |Area | System id |Selector| |47 |0005 | 80 |F8000 | 0000 | 0001 |0001 |010203040506|tcp port| =================================================================== | AFI Internet (One possible V7 assignment < 20 | | bytes | | 1 | 2 | 3 | 5-7 | 8-9 |10-15 | | |AFI| ver |IANA| AAI | RD | System id |Selector| |33 | 80 | 01 |F8000 | 0001 |010203040506|tcp port| ==================================================== | private network - | | bytes | | 1 | 2 | 3-8 | 9 | |AFI | net | system id |tcp port| | 49 | 01 | 010203040506 | 01 | ==================================== 2.2) Ease getting pre-assigned NSAP addresses without Registration To encourage Internet growth, it has to be easy to get a block of addresses that will be guaranteed to be unique. With NSAPs, there are many methods of obtaining addresses, some of which do not involve having to ask anyone for addresses for local or private networks. The example above with the "LOCAL" AFI allows a user to define what ever he wants within the network. Any of the public addressing plans can be used, such an X.121 address, or the E.163 or E.164. With AFI values can be assigned for IPX or IPv4, so that anyone with a current address of that form automatically can have an NSAP address. And addresses are long enough for new hierarchical address assigning schemes, such as the GOSIP scheme. Routing doesn't care how many schemes there are or how addresses have been handed out -- routing just treats it like a pile of bits and routes to the longest matching address prefix. A new AFI value could be assigned for the Internet's New Generation. Address under this AFI could use the IANA procedures to assign and register the new addresses. Multicast addresses assignments proposed in ISO, are also distributed in the same manner unicast are distributed. One of the AFIs, means Multi-cast "local " which is can only be used in a private network. So, multi-cast and a unicast address can be assigned for private networks without address administration. 2.3) Embedded subnet Addresses Some topologies consist of routing across large clouds such as ATM or X.25. ATM claims to use NSAPs, but in reality the large public ATM nets will route based on E.164 (telephone numbers). In clouds such as these, it is possible to get routing across these clouds for "free" -- no configuration and no routing messages. The E.164 addresses Address space is defined as: =================================================================== | bytes | | 1 | 2 - 8 | 9 -15 | 16 | ------------------------------------------------------------------- | E.164 | |AFI| IDP | private network assignment | |45 | 91 13 19 36 33 00 00 | 0000 0001 0001 01 | tcp port | ------------------------------------------------------------------- Simply use the point of attachment of the cloud as Inter-Domain- Portion (IDP) of an E.164 address, which we'll call again the "network prefix", and assign the rest of the address as convenient within the private net hanging off the large cloud. It is not necessary for every address to have this form in order to get the benefit. If some portion of addresses can be assigned this way, it offloads the routing protocol and the system administrators by that much. 2.4) Routing by Prefixes ISO Routing is to the longest matching address prefix. CIDR routing also uses the match of the longest matching addresses prefix. NSAP prefixes simply carry on in a larger space the basic concepts of CIDR. It is desirable, whatever way addresses are handed out, that there be good summarization of addresses possible. All the current schemes for assigning network prefixes will result in addresses that match the topology pretty well. After CIDR, the network operators will be used to setting up routing plans on the basis of longest matching prefix addresses. Growing into NSAP space will follow naturally after the CIDR work. 3.) Distributed Administration of NSAP addresses Two types of administration will aid the Internet: a) easy administration of private or local networks, b) A continuation of the fine work the Internet Address Naming and Authority and NIC (IANA). The NSAP address space administration allows both types of administration ISO has delegated large portions of the NSAP Address space to other authorities such as the Internet. The Internet could obtain a set(s) of network address space to administer from ISO. Once assigning a block to the Internet, ISO has no more interaction so the IANA could operate as usual. Local or private numbers provide a basis for one part of the ISO space. This is an example of a "no-administration" for assignment of NSAPs. As long as you don't connect to the rest of the internet, you can start with the "local" AFI and define you own NSAP. Users of existing ISO address NSAP space may want to register for Internet routing by Internet-Routing Registration authorities. One benefit of the NSAP addresses are that the registration authorities can expand the current CIDR architecture to include NSAP addresses. Current work in RIPE on what information to keep in CLNS routing register has produced the following draft RIPE document, "CLNS routing-domain object for the RIPE database" by Sue Hares and Hank Steenman. Registration of routing for CIDR requires registration of: 1) Network prefixes - such as 128.2.0/10 (/10 = bit length 10) 2) aggregates and aggregation policy, 3) assignment of Autonomous System for Routing Domains 4) routing policy The registration of NSAP addresses requires the exact type of information: 1) Network prefixes - such as 39.840F/24 (bit length 24) 2) aggregates and aggregation policy, 3) assignment of Routing Domain Identifiers for Routing Domains 4) routing policy The benefits of using NSAP mechanism is that tools build to query or debug the CIDR network can be grown into NSAP tools because the basic databases are extremely similar. 4. Acknowledgements The author wishes to thank Yakov Rekhter(IBM) and Peter Ford (Los Almos Labs) for their "encouragement" to write this information RFC, and for their early review of the document. However, all heretical ideas and comments can be only blamed on my pre-occupation the pragmatism of doing what it takes to get networks working. My thanks to Allison Malkin for our discussion at the Seattle IETF that reminded me why I started to drain the ISO swamp. 5. References [1] ISO 8473/Addendum 2 - Information Processing Systems - Data Communications - Protocol for Providing the Connectionless-mode Network Service, 1988. [2] "CLNS routing-domain object for the RIPE database, version 3.b - RIPE working draft Sue Hares and Hank Steenman [3] Fuller, V., Li, T., Yu, J, and Varadhan, K., "Class-Less Inter- Domain Routing: an Address Assignment and Aggregation Strategy", RFC1519, September 1993 [4] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation with CIDR", RFC1518, September 1993 [5] Rekhter, Y. "Exchanging Routing Information Across Provider Boundaries in CIDR Environment" [6] Hares, S., Wittbrodt, C., "Essential Tools for the OSI Internet" Authors' Addresses Susan Hares Merit, Inc 1071 Beal Avenue Ann Arbor, MI 4810x Phone: (313) 936-2095 Email: skh@merit.edu From bound@zk3.dec.com Sat May 21 00:04:21 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA16696 for ; Sat, 21 May 1994 00:10:48 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA05680; Fri, 20 May 94 21:05:48 -0700 Received: by xirtlu.zk3.dec.com; id AA19570; Sat, 21 May 1994 00:04:27 -0400 Message-Id: <9405210404.AA19570@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Bob Moskowitz (Chrysler) thoughts today on IPng Date: Sat, 21 May 94 00:04:21 -0400 X-Mts: smtp ------- Forwarded Message Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from decvax.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Apr94-1041AM) id AA17413; Fri, 20 May 1994 07:51:46 -0400 Received: from murtoa.cs.mu.OZ.AU by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA06698; Fri, 20 May 1994 07:51:41 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA03526; Fri, 20 May 1994 21:10:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03499; Fri, 20 May 1994 20:56:57 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06172; Fri, 20 May 1994 21:25:18 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA00957; Fri, 20 May 94 06:25:58 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ar05319; 20 May 94 11:15 GMT Date: Fri, 20 May 94 06:21 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Noel Chiappa To: big internet Subject: Re: Thoughts on the IPng situation... Message-Id: <20940520112102/0003858921NA2EM@mcimail.com> >At that point, whether you pick TUBA or SIPP or whatever is more of a >political statement, than a technical one. :-( For the most part, I am too busy making TCP/IP happen at Chrysler in a BIG way to participate in these conversations. But.... There is one VERY big criteria for us corporate folks that will drive us to an IPng, given a business need. That is the DOS/Windows migration plan. Forget your UNIX work, it does not represent a significant number of install machines in the corporate world (yes I help set Chrysler Finance up with 3,000+ NeXtstep systems). Now all too many DOS/Windows systems are already running dual stack, IP and IPX. It might actually happen later this year that Novell will really get NWIP to the point that it can be used large scale, but my colleagues that do IPX are not holding their breath. This tends to lead me, personally, to be very much concerned about a dual stack transition. I want to REPLACE the IP kernel in DOS with an IPng kernel. Yes I have worked with DLL implementations and found them lacking. Perhaps we will soon have VxD implementations, but that is VERY hard and I would doubt if an IPng would do that out the door. The next big criteria is address migration. I would want a clean port of my IP addresses to IPng addresses. In the past year, the corporate side of our network (still waiting on numbers from engineering) went from 3,000 IP interfaces to 8,800 interfaces (according to our HP OpenView). Dreaming up a new addressing scheme is not all that much fun. As it is we are fighting a DNS/X.500/NDS naming fight... So from where I stand today (and granted I have only scanned the drafts), SIPP looks good to me and I would recommend it to my colleagues. But then if I am shown how easy the same items are with TUBA or CATNIP, or TURNIPP, I could end up needing to reconsider. My voice carries some weight here. But this is not Chrysler's position, yet. Bob Moskowitz Chrysler Corp ------- End of Forwarded Message From bound@zk3.dec.com Sat May 21 01:42:12 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA16945 for ; Sat, 21 May 1994 01:45:33 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA08462; Fri, 20 May 94 22:43:20 -0700 Received: by xirtlu.zk3.dec.com; id AA20660; Sat, 21 May 1994 01:42:18 -0400 Message-Id: <9405210542.AA20660@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: To-Do's A.S.A.P. IMHO Date: Sat, 21 May 94 01:42:12 -0400 X-Mts: smtp Address changes: Can someone put together real short the layout of the suggested address format so it can be analyzed in depth from an implementation perspective on a host and router, as a quick logic check. The other question is what do any address changes do to the existing routing protocols available to us for the Internet? Transition Requirements: I find that we still have to make transition lists annoying but OK. I am making a list too and I encourage others to do the same. But lets schedule a transition meeting very soon that looks at how do you do those requirements on the East Coast. I don't care where its hosted here but we need Bob Gilligan there not just for IPAE but because he has really looked at this too from an implementation perspective as I have. And don't tell me you can't look at this right now from an implementation perspective because you can, you just don't know what the Transition spec will be (on this I agree). But any good implementor has an idea of where the pain and engineering cost will be to build transition software for IPng, unless they are not keeping up with the pack, the discussions, and the TUBA and SIPP Transition specs. Be real. A great trick in the machavellian model of political science is to keep re-inventing the problem when you don't want someone to build a solution to the problem just yet. I won't go into several other tricks. They are not done on purpose, most often its a side affect of working in Corporate America (I don't have a clue about Europe or Asia or other cultures in this space). In addition both TUBA and SIPP did put requirements in their drafts of what they believed the requirements are and spent some thought on why these are requirements. We don't have to re-invent the wheel completely here folks. I would also like Yakov and Peter to be there. This meeting in my mind should not be an architecture meeting but an engineering meeting where we take the requirements and figure out 'how to' from a router and host perspective. Lets get the requirements done by June 1st? Then maybe we can go for meeting the week of June 6th. Do we need two days? A good thing to ask oneself when thinking about transition requirements is are they the same as customer assumptions. For example in the Bob Moskowitz mail I just sent he sounded awful close to saying that he does not want the headache of dual stacks and might just want IPng ONLY on his PC's. But others will say I do want dual stacks. The point is you need to make sure you cover the bases. As Ross said if its too complex then maybe we can't do it. But thats the part we need to analyze and not assume something is to complex without much technical thought from an implementation perspective. Also in the equation if a vendor can make a profit from doing something very complex should also be in the equation. This is an engineering perspective as opposed to a computer science perspective. BBN sounds like a good neutral place for the meeting if John can swing it? EIDs: We need a definition right? I am writing one right now. This is not rocket science. How about figuring this definition out by June 1st? If we get 8 definitions we can probably come up with one with a little work. And put this behind us and move on. I would be glad to assimilate them and produce common thoughts and where people don't see eye-to-eye at all. I still think Steve Deering gave us the different models for EIDs and we can just take SIPP out of the context and probably get a definition real quick. I think part of the test should be to ask Noel if he thinks we got it right. thanks /jim From lixia@parc.xerox.com Sat May 21 17:13:17 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18810 for ; Sat, 21 May 1994 20:14:11 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14630(6)>; Sat, 21 May 1994 17:13:30 PDT Received: by redwing.parc.xerox.com id <57153>; Sat, 21 May 1994 17:13:19 -0700 Date: Sat, 21 May 1994 17:13:17 PDT Sender: Lixia Zhang From: Lixia Zhang To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: To-Do's A.S.A.P. IMHO In-Reply-To: Your message of Fri, 20 May 1994 22:42:12 -0700 Message-ID: > Address changes: > > Can someone put together real short the layout of the suggested address > format so it can be analyzed in depth from an implementation perspective > on a host and router, as a quick logic check. If there is one I'd like to see it too since I left the meeting earlier (but I'm not sure there is one yet :-( > EIDs: > > We need a definition right? I am writing one right now. I'm not sure whether we need a new definition for EID or we just need an agreement with the definitions--different people seem to have different definitions. > This is not > rocket science. How about figuring this definition out by June 1st? > If we get 8 definitions we can probably come up with one with a little > work. And put this behind us and move on. I would be glad to > assimilate them and produce common thoughts and where people don't see > eye-to-eye at all. As an input to your collection: at one dinner several of us tried to list different EID definitions (Steve Deering took some notes so he can correct me): 1 an ID to identify an IP entity (e.g. the IP module running in a host). 2 an ID to identify a transport level entity. This one may or may not have one-to-one correspondence with (1). 3 a running instance of transport entity, e.g. one end of a TCP connection. 4 a process. I recall we listed 5. Steve, what's the 5th one? > I still think Steve Deering gave us the different > models for EIDs and we can just take SIPP out of the context and > probably get a definition real quick. ?? not sure what you were talking here. I see 3 steps in this EID exercise/the EID WG agenda: - an agreement on the definitions. Is the above list correct? - understand the requirements of each EID (e.g. as a transport entity, TCP probably desire a fixed size ID, and hopefully not too big. The life time may also be an issue) - based on the requirements, find ways to produce each of the EIDs. Personally I think IP(ng) has the responsibility for (1) in the above, i.e. have a UID to identify an IP entity to accomplish things like mobility. Whether transport protocols or others use this UID for their purpose is a decision of their own that the proposed EID WG should look into. Lixia From smb@research.att.com Sat May 21 20:47:44 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18899 for ; Sat, 21 May 1994 20:48:22 -0400 From: smb@research.att.com Message-Id: <199405220048.UAA18899@picard.cmf.nrl.navy.mil> Received: by gryphon; Sat May 21 20:47:45 EDT 1994 To: Lixia Zhang cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: To-Do's A.S.A.P. IMHO Date: Sat, 21 May 94 20:47:44 EDT 2 an ID to identify a transport level entity. This one may or may not have one-to-one correspondence with (1). 3 a running instance of transport entity, e.g. one end of a TCP connection. 4 a process. Let me repeat my suggestion of using a random 128-bit number, though with an answer to Lixia's objection. She pointed out, quite correctly, that hosts won't generate random numbers well unless told how to. Let me propose the following. Given that IPng hosts will (I hope) all have strong authentication, they'll need some cryptographic hash function H (i.e, something like MD5 or SHA). Let R0 = H(SysID || hostname || TOD) That's probably quite random, even with collisions in the SysID space. Let Ri+1 = H(Ri || TOD) I suggest including the TOD in the feedback loop so that if some collision ever occurs, it won't be propagated. From lixia@parc.xerox.com Sat May 21 17:51:50 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18909 for ; Sat, 21 May 1994 20:52:42 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14622(7)>; Sat, 21 May 1994 17:52:03 PDT Received: by redwing.parc.xerox.com id <57153>; Sat, 21 May 1994 17:51:52 -0700 Date: Sat, 21 May 1994 17:51:50 PDT Sender: Lixia Zhang From: Lixia Zhang To: ipng@cmf.nrl.navy.mil Subject: some thought after the retreat Message-ID: I see the IPng retreat as a great success. I wish it had happened earlier. It's a success because it started the process of unifying all the effort towards building a single IPng. I second Jim's suggestion of scheduling a face-to-face meeting to reach an agreement on transitions soon since this issue did not get enough time at the retreat. I also feel the need for a face-to-face meeting on addressing and routing to nail down more details. I know nobody likes travel, but telechat just does not seem to do the job. Although a new IPng WG wont officially start until Toronto IETF, I hope the work would be well underway by then. Lixia From brian@dxcoms.cern.ch Sun May 22 14:39:44 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA20166 for ; Sun, 22 May 1994 08:40:18 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22148; Sun, 22 May 1994 14:39:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA06742; Sun, 22 May 1994 14:39:44 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405221239.AA06742@dxcoms.cern.ch> Subject: Re: Bob Moskowitz (Chrysler) thoughts today on IPng To: ipng@cmf.nrl.navy.mil Date: Sun, 22 May 1994 14:39:44 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 979 Jim, I'm not too impressed by the Bob Moskowitz argument. Today, we have to install an IPX stack and an IP stack on our PCs. Tough, it's another install procedure on top of maybe 20 that it takes to configure a PC adequately for professional use. When I installed the home-access package on the PC I'm using right now, I just put in the diskettes, pressed the button, and got IP, IPX and RLN (remote LAN node) in one go. This is not a big deal. In any case, as I said elsewhere, it is just a PRODUCT PACKAGING issue. If I update a VMS host from UCX to UCXng, I would expect that I would end up with a dual stack (IP and IPng) in ANY scenario. Just look at Bill Duane's foils BTW. As I read SIPP, it is a dual stack proposal (hosts can talk IPv4 as well as SIPP during transition). TUBA is the same. (AEIOU was the same :-) Whether there is one or two object code modules in there is irrelevant; you can have dual stack behaviour and a single installation package. Brian From bound@zk3.dec.com Sun May 22 23:25:26 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA21883 for ; Sun, 22 May 1994 23:30:43 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA13046; Sun, 22 May 94 20:25:34 -0700 Received: by xirtlu.zk3.dec.com; id AA25040; Sun, 22 May 1994 23:25:32 -0400 Message-Id: <9405230325.AA25040@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Bob Moskowitz (Chrysler) thoughts today on IPng In-Reply-To: Your message of "Sun, 22 May 94 14:39:44 +0200." <9405221239.AA06742@dxcoms.cern.ch> Date: Sun, 22 May 94 23:25:26 -0400 X-Mts: smtp Brian, All good points regarding 'installation of dual stack' in fact it could be a triple stack. But what if folks want to just get rid of all stacks except for IPng? If that is a possibility then what do we have to do in the transition to cover that case? I am not ready to tell my customers THEY HAVE TO HAVE DUAL stack machines anymore than I want to tell them I won't support dual stack machines. Its just the flip side of the transition coin. And I think we need to think about it. As a caveat I don't ever perceive IPng only routers its the hosts I am thinking about. So this is really a host only discussion. /jim From bound@zk3.dec.com Sun May 22 23:48:45 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA21915 for ; Sun, 22 May 1994 23:51:27 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA14134; Sun, 22 May 94 20:48:52 -0700 Received: by xirtlu.zk3.dec.com; id AA25515; Sun, 22 May 1994 23:48:51 -0400 Message-Id: <9405230348.AA25515@xirtlu.zk3.dec.com> To: Lixia Zhang Cc: ipng@cmf.nrl.navy.mil Subject: Re: To-Do's A.S.A.P. IMHO In-Reply-To: Your message of "Sat, 21 May 94 17:13:17 PDT." Date: Sun, 22 May 94 23:48:45 -0400 X-Mts: smtp => Address changes: => => Can someone put together real short the layout of the suggested address => format so it can be analyzed in depth from an implementation perspective => on a host and router, as a quick logic check. >If there is one I'd like to see it too since I left the meeting >earlier (but I'm not sure there is one yet :-( Yeah this is important for us to not sit on too long I just stopped all major prototype development Friday until I see what the address looks like. We are starting to build caches and very host specific things for interoperability testing. This is complex code and requires much debugging and I don't want to do this twice if I can avoid it. No problem not casting code in concrete but addresses in headers is pretty major. This will affect all public domain code too. But we probably should keep this to ourselves until we think its really an idea that will pursued. => EIDs: => => We need a definition right? I am writing one right now. >I'm not sure whether we need a new definition for EID or we just need >an agreement with the definitions--different people seem to have >different definitions. I agree I really don't want to just re-write what Noel and Steve have done. Mine is pretty close to these two but I am a real hard liner on NO ROUTING SCOPE AT ALL in the EID. No overload junk or none of that hog-wash. => This is not => rocket science. How about figuring this definition out by June 1st? => If we get 8 definitions we can probably come up with one with a little => work. And put this behind us and move on. I would be glad to => assimilate them and produce common thoughts and where people don't see => eye-to-eye at all. >As an input to your collection: at one dinner several of us tried to >list different EID definitions (Steve Deering took some notes so he >can correct me): >1 an ID to identify an IP entity (e.g. the IP module running in a > host). >2 an ID to identify a transport level entity. This one may or may not > have one-to-one correspondence with (1). >3 a running instance of transport entity, e.g. one end of a TCP > connection. >4 a process. >I recall we listed 5. Steve, what's the 5th one? => I still think Steve Deering gave us the different => models for EIDs and we can just take SIPP out of the context and => probably get a definition real quick. >?? not sure what you were talking here. I will send it after this response. >I see 3 steps in this EID exercise/the EID WG agenda: >- an agreement on the definitions. Is the above list correct? >- understand the requirements of each EID (e.g. as a transport entity, > TCP probably desire a fixed size ID, and hopefully not too big. > The life time may also be an issue) >- based on the requirements, find ways to produce each of the EIDs. This sounds like an excellent strategy. >Personally I think IP(ng) has the responsibility for (1) in the above, >i.e. have a UID to identify an IP entity to accomplish things like >mobility. I agree with you on this. >Whether transport protocols or others use this UID for their purpose >is a decision of their own that the proposed EID WG should look into. I think we can use (1) to get a start on (2) and (3). (4) to me is not an EID. Process IDs are a different issue I think that EIDs. They are an issue but I think at a higher layer and would need agreement across multiple operating system environments. I think Sprite has come to some conclusions on this and HP has done something with distributed processes that are in fact unique on a LAN ????? But not sure??? I do see the value for RPC too, just not sure it buys us anything from a network layer????? /jim Lixia From bound@zk3.dec.com Sun May 22 23:50:53 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA21929 for ; Sun, 22 May 1994 23:57:06 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA14223; Sun, 22 May 94 20:51:00 -0700 Received: by xirtlu.zk3.dec.com; id AA25550; Sun, 22 May 1994 23:50:59 -0400 Message-Id: <9405230350.AA25550@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Steves EID mail to SIPP and some Models Date: Sun, 22 May 94 23:50:53 -0400 X-Mts: smtp I like Model H. SIPP is not the issue as I said just look at them to explain the different approaches. /jim ------- Forwarded Message Return-Path: sipp-request@sunroof2.eng.sun.com Received: from decvax.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Apr94-1041AM) id AA17738; Fri, 13 May 1994 03:55:58 -0400 Received: from Sun.COM by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA01412; Fri, 13 May 1994 03:55:53 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02512; Fri, 13 May 94 00:49:58 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04066; Fri, 13 May 94 00:49:11 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04565; Fri, 13 May 94 00:50:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04559; Fri, 13 May 94 00:50:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28247; Fri, 13 May 94 00:48:47 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA02476; Fri, 13 May 94 00:49:38 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14674(6)>; Fri, 13 May 1994 00:49:25 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 13 May 1994 00:49:18 -0700 To: sipp@sunroof2.eng.sun.com, big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: addressing/locating/identifying models Date: Fri, 13 May 1994 00:49:13 PDT From: Steve Deering Message-Id: <94May13.004918pdt.12171@skylark.parc.xerox.com> Sender: sipp-request@sunroof.eng.sun.com [Warning: if you don't like Noelgrams, you probably won't want to wade through this either.] There seems to have been some miscommunication or ambiguity about some of the possible addressing/locating/identifying models for IPng (and internet datagram protocols in general). I don't know if this will help, but here is my attempt to characterize/categorize the various approaches. I have prosaically labelled the various models Model A, Model B, etc. for now; perhaps adherents of particular models will offer more evocative names (such as Paul's "VANITY") that we can use in future to refer unambiguously to particular models (for example, I'd like to know what model or models people have in mind when they ask for "pure EIDs"). In any case, I would welcome additions/deletions/corrections to this list. In the following, hierarchical addresses are illustrated as a sequence of components, C1, ..., Cn-1, Cn, where C1 is the highest-order (top-level) component. The last component, Cn, is the "host part". The "subnet number" in an IPv4 address or the "area ID" in a TUBA NSAP address would then be component Cn-1. The illustrations are not intended to imply that the components are of fixed size (i.e., they may be of varying widths, and the widths may either be encoded in the addresses themselves, as with IPv4 Class A, B, and C network numbers, or externally by masks or bit counts, as with IPv4 subnet numbers). Nor are the illustrations intended to imply that the components are necessarily contiguous in the packet headers. The intention is to convey the semantics, not the syntax of addresses. An "internet entity" is here defined as an internet-layer source and/or sink of datagrams. Usually an internet-layer corresponds one-to-one with a "host", "node", or "system"; however, it is possible (though uncommon at present) to have more than one internet entity residing in the same physical device (e.g., multiple "logical hosts" in the same "physical host") or for an internet entity to be moved from one physical device to another. In the illustrations below, the parts labeled "locator" are those parts required to route a datagram to its destination internet entity. The parts labeled "identifier" are those that upper-layer protocols (e.g., transport) may treat as an unambiguous identifier of an internet entity. I distinguish between the case where the last component of an address can hold a "device ID" and the case where it cannot. For "device ID", read a number large enough to be globally unique (but which may, in fact, not be globally unique) that is hardwired or hand-configured into a device or an interface. The canonical example is an Ethernet or IEEE 802 address. This does not including addressing/locating/identifying models for multicast, broadcast, source routing, encapsulation, flows, or virtual circuits -- just plain ol' datagram unicast. I also have not listed all possible models, but only those that have, to my knowledge, been implemented or proposed. Here we go.... MODEL A <---------- locator ---------> +------+ +------+------+ | C1 | . . . | Cn-1 | Cn | +------+ +------+------+ <-------- identifier --------> Constraint: the Cn component is too small to hold a device ID. examples: - IPv4 address (n = 2 or more) - Appletalk address (n = 2) - SIPP global 64-bit address (n = 3 or more) MODEL B <---------------- locator ---------------> +------+ +------+------------------+ | C1 | . . . | Cn-1 | Cn | +------+ +------+------------------+ <-------------- identifier --------------> This differs from Model A in that the Cn component can hold a device ID. However, Cn is not required to be globally unique, but only unique within the topological cluster labelled C1, ..., Cn-1. Enables server-less autoconfiguration of addresses by appending device ID to overheard C1, ..., Cn-1 value. examples: - IPX address (n = 2) - TUBA NET, i.e., NSAP address minus SEL (n = 4 or more) MODEL C <---------------- locator ---------------> +------+ +------+------------------+ | C1 | . . . | Cn-1 | Cn | +------+ +------+------------------+ <------ identifier -------> In this model, the identifier is some number of trailing components, more than one but less than n, that form a globally-unique value. Server-less autoconfiguration possible if device ID really is globally unique. example: - SIPP address sequence, where final 64-bit element is a SIPP address containing a subnet number plus a globally- administered IEEE 802 unicast address. MODEL D <-------- locator --------> +------+------------------+ | Cn-1 | Cn | +------+------------------+ <------ identifier -------> Usable for communication only between nodes located in the same C1, ..., Cn-2 cluster, e.g., the same subnetted site. Server-less autoconfiguration possible. example: - SIPP local-use address containing a subnet number plus an IEEE 802 address. MODEL E ("VANITY") <------------------- locator ------------------> +------+ +------+------------------------+ | C1 | . . . | Cn-1 | Cn | +------+ +------+------------------------+ <------ identifier ------> In this model, the identifier is the last component of the address. Server-less autoconfiguration possible if device ID really is globally unique. examples: - XNS address (n = 2) - Pip FTIF chain + ID (n = 2 or more) - SIPP address sequence, where final 64-bit element is a SIPP address containing a globally-administered IEEE 802 unicast address. MODEL F <------- locator --------> +------------------------+ | Cn | +------------------------+ <------ identifier ------> Usable for communication only between nodes located in the same C1, ..., Cn-1 cluster, e.g., the same subnet or area. Server-less autoconfiguration possible. examples: - Pip ID, when used between nodes on the same link - SIPP local-use address containing an IEEE 802 address. MODEL G <---------- locator ---------> <------ identifier ------> +------+ +------+------+ +------------------------+ | C1 | . . . | Cn-1 | Cn | | I | +------+ +------+------+ +------------------------+ In this model, the locator does not include the identifier, and the Cn component is too small to hold a device ID. example: - TUNE over IPv4 or SIPP - SIPP adress sequence, where the elements preceding the last element are sufficient to route to a node - Nimrod? MODEL H <---------------- locator ---------------> <------ identifier ------> +------+ +------+------------------+ +------------------------+ | C1 | . . . | Cn-1 | Cn | | I | +------+ +------+------------------+ +------------------------+ Same as model G, except the Cn component can hold a device ID, so server-less autoconfiguration of the locator is possible. example: - TUNE over IPX, TUBA, or SIPP - SIPP adress sequence, where the elements preceding the last element are sufficient to route to a node - Nimrod? - ---------------------------------------------------------------------------- Some observations about SIPP: SIPP supports all of these models, except model B. SIPP constrains the identifier to be exactly 64 bits. SIPP allows interoperation between nodes using any of the different supported models. ------- End of Forwarded Message From bound@zk3.dec.com Sun May 22 23:56:32 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA21952 for ; Mon, 23 May 1994 00:01:43 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA14491; Sun, 22 May 94 20:56:40 -0700 Received: by xirtlu.zk3.dec.com; id AA25626; Sun, 22 May 1994 23:56:38 -0400 Message-Id: <9405230356.AA25626@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: An explantion of EIDs and Locators Date: Sun, 22 May 94 23:56:32 -0400 X-Mts: smtp See discussion of gronks and fnortzes attached. I saved this one for just such a time. /jim Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from decvax.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Apr94-1041AM) id AA29259; Fri, 8 Apr 1994 01:00:40 -0400 Received: from murtoa.cs.mu.OZ.AU by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA10108; Fri, 8 Apr 1994 01:00:17 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA11856; Fri, 8 Apr 1994 14:43:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA11807; Fri, 8 Apr 1994 14:26:31 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03134; Fri, 8 Apr 1994 03:20:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03312; Thu, 7 Apr 94 13:20:15 -0400 Date: Thu, 7 Apr 94 13:20:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9404071720.AA03312@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ericf@arc.boeing.com Subject: Re: Introducing proxy aggregations? Cc: jnc@ginger.lcs.mit.edu it is unreasonable to imagine that that company would be willing to readdress as part of the bargain. ... the "new carrier" is not likely to insist that the company re-address ... For this reason, I have always thought that "provider based addressing" is unrealistic and A Bad Thing. To me, it is merely another instance that significant percentages of the IETF do not understand even elementary market realities. Perhaps the researchers could retort that significant percentages of the IETF do not understand even elementary technical realities. (Sorry, couldn't resist; too good a line! :-) Let me try a "real-world" analogy to "provider based addressing" which may make the extent of my inability to grok your statement clear. Suppose I have a small firm which is renting space from building X. We get a better deal on space in building Y, so we move to a different "space provider". However, we insist at the same time that we don't want to change our address, that our deliveries continue to come to our old address. Any landlord would look at you like you're a candidate to be comitted, right? I can understand the desire of people to have "names" for their computers which don't vary as their location in the topology changes. (The fact that I'm Noel in Virginia and Seattle is sort of useful! :-) Let's call these names "gronks". However, in return, please try and understand the needs of routing. (Not the needs of the routing community; the things of which I speak are no more escapable than the laws of thermodynamics! :-) If routing is going to scale (i.e. not have costs on the order of O(N), where N is the number of distincyt destinations in the network) it needs to work with "names" for things which have topological significance; i.e. when you pick something up, and move it to a different place in the topology, it gets a different "name" for the routing to work with. Let's call these names "fnortzes". (I should interject that there are ways to constrain the topology so that if you move from one provider to another within a local area of the topology, to which all the providers are attached, the move can be made "invisible" [the routing will still know about it, obviously] both outside and inside at the cost of a certain amount of overhead, approximately O(N) in the number of things which have moved from their original provider. If you pay that cost, it's not visible from your name that you've changed providers. It may not be practical to enforce this restriction, the costs may also become too large, and in any case, it only works if your reattachment point is inside that local area of the topology. Some variants of this scheme turn into having fnortzes, just under the sheets where the users can't see them.) So, you have two groups, with diametrically opposed needs. You can't keep them both happy at the same time, with one thing! Either a) one loses, or b) you have two separate things. I can guarantee you that routing (like thermodynamics :-) isn't going to lose; it *is* the rules. You only get to chose whether i) you have one name, and it changes when you move to a different provider, or ii) you have two names, so everybody can be happy. I think the latter is the way to go, but that's just my opinion. Noel PS: If it isn't obvious, "gronks" are EID's, and "fnortzes" are locators. From Greg_Minshall@Novell.COM Mon May 23 08:46:05 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA24002 for ; Mon, 23 May 1994 11:48:59 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04844; Mon, 23 May 94 09:48:00 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA16270; Mon, 23 May 94 08:46:07 PDT Date: Mon, 23 May 94 08:46:05 PDT Message-Id: <9405231546.AA16270@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Random thoughts On dual stack: Like Brian, i think a lot of "dual stack" can be covered up by "packaging issues"; i think the ability to use an IPv4 address as the "seed" for an IPng address is crucial, though, for two reasons: 1) setting up a dual stack (IPv4 and IPng) should require EXACTLY THE SAME CONFIGURATION INFORMATION used to set up an IPv4 node today; 2) IPng should be able to thrive in a world which has mechanism (procedures, numbers already assigned, etc.) in place to allocate IPv4 addresses. On meetings on transition: I will be in Boston June 28-July 7. If we can set a meeting time soon enough, i can reserve one or two of those days for this meeting. Yes, it would be nice if it happened earlier; yes there are other times i could be in Boston. On meetings on addressing and routing: I agree with Lixia - it sounds to me like there are big issues here left to be resolved. Since we are doing the transition meeting on the e. coast, maybe have the addressing and routing on the w. coast? We'd be happy to volunteer a location in the bay area (i'd have to scout around, but we have a number of places which could hold 15 person or so meetings). On EIDs: At the retreat it seemed to be the consensus that the "identifier" and the "locator" would be the same thing (during Steve's talk on Friday am). I.e., that the thing that identifies which IP module is decapsulating a packet, and to which transport module instances that IP module will hand off packets (based on the "payload type" == "transport id"). We punted on EIDs. Steve said "*if* a transport module is going to rely on something in the internet header to identify the source and destination, it should rely on the identifier/locator (but, not on the entire source route/provider selection crud)". This was accepted by all around the table (Steve specifically asked; i noted no objection). Of course, today TCP and UDP *do* rely on these, so they should use the address, but not the entire source route. There was some thought we would cause some group to spin up to revise TCP and/or UDP to be independent of addressing in the internet header. I don't feel this is a big deal w.r.t. IPng. Greg From crb@faline.bellcore.com Mon May 23 15:33:48 1994 Return-Path: crb@faline.bellcore.com Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA25596 for ; Mon, 23 May 1994 15:35:59 -0400 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA25988; Mon, 23 May 1994 15:37:12 -0400 Received: from localhost (localhost [127.0.0.1]) by faline.bellcore.com (8.6.7/8.6.6) with SMTP id PAA21294 for ; Mon, 23 May 1994 15:33:52 -0400 Message-Id: <199405231933.PAA21294@faline.bellcore.com> X-Authentication-Warning: faline.bellcore.com: Host localhost didn't use HELO protocol To: ipng-wp@harvard.edu Subject: Second draft of IPng white paper - IPng Support for ATM Services Date: Mon, 23 May 94 15:33:48 -0400 From: Chris Brazdziunas This is the second draft for the IPng White Paper entitled, "IPng Support for ATM Services". Very minor changes have been made from the few comments I received. The status of memo section has not been included. chris ---------- Chris Brazdziunas crb@faline.bellcore.com ------------------------------------------------------------------------------- Network Working Group C. Brazdziunas INTERNET-DRAFT Bellcore Category: Informational March 1994 IPng Support for ATM Services Executive Summary This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. IPng should provide support for existing and emerging link technologies that it will be transported over. Link technologies like Ethernet simply multiplex traffic from upper layer protocols onto a single channel. "Sophisticated" link technologies like ATM are emerging in the marketplace allowing several virtual channels to be established over a single wire (or fiber) potentially based on an applications' network performance objectives. Support for both "sophisticated" (ATM) and existing link technologies needs to be considered in an IPng candidate. End-to-end applications will communicate through a network where IPng packets travel across subnetworks such as Ethernet and Hippi and also more "sophisticated" link levels such as ATM. Though initial support for IPng over ATM subnetworks will not facilitate a virtual circuit per application, the hooks to provide such a mapping should be in place while also maintaining support for the transport of IPng packets across conventional subnetworks. Application support for QOS-based link level service requires that the following types of ATM information be mappable (or derivable) from the higher level protocol(s) such as IPng: source and destination(s) addresses, connection quality of service parameters, connection state, and ATM virtual circuit identifier. Some of these mappings may be derivable from information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier should be efficiently derivable from IPng packet information. An IPng candidate should provide evidence that the mapping from an applications' IPng packets to ATM virtual circuit(s) can be accomplished in a heterogeneous Internet architecture keeping in consideration the gigabit/sec rates that IPng/ATM subnetworks will eventually be operating at. Brazdziunas [Page 1] INTERNET-DRAFT IPng Support for ATM Services March 1994 1. Introduction This paper describes parameters that are needed to map IPng (or any protocol operating above the link level) to ATM services. ATM is a "sophisticated" link level technology which provides the potential capability for applications at the TCP/UDP level to map to a single ATM virtual circuit for transport across an ATM network(s) customized to the network performance and traffic requirements for that application. This is a step above many of today's existing link technologies which can only support a single level of network performance that must be shared by all applications operating on a single endpoint. The future Internet will be comprised of both conventional and "sophisticated" link technologies. The "sophisticated" features of link layers like ATM need to be incorporated into an internet where data travels not only across an ATM network but also several other existing LAN and WAN technologies. Future networks are likely to be a combination of subnetworks providing best-effort link level service such as Ethernet and also sophisticated subnetworks that can support quality of service-based connections like ATM. One can envision data originating from an Ethernet, passing through an ATM network, FDDI network, another ATM network, and finally arriving at its destination residing on a HIPPI network. IPng packets will travel through such a list of interconnected network technologies as ATM is incorporated as one of the components of the future Internet. To support per application customizable link level connections, four types of ATM information should be derivable from the higher level protocol(s) like IPng. This ATM information includes: source and destination ATM addresses, connection quality of service parameters, connection state, and an ATM virtual circuit identifier which maps to a single IPng application (i.e. single TCP/UDP application). Some of these mapping could potentially be derivable through information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier needs to be efficiently mappable from IPng packet information. Organization of this white paper is as follows. First the characteristics of ATM are described focusing on functions that are not provided in today's LAN technologies. This section provides background information necessary for the following section describing the parameters needed to map IPng services to ATM services. Brazdziunas [Page 2] INTERNET-DRAFT IPng Support for ATM Services March 1994 2. Related Work Issues and network architectures for the transport of IP (IPng) packets over ATM have been widely discussed. For information on IP/ATM subnet and end-to-end architectures see [7]. 3. Terminology In this white paper, the term "application" refers to a process or set of collective processes operating at the TCP/UDP level or above in the protocol stack. For example, each instance of "telnet" or "ftp" session running on an end station is a distinct application. 4. Characteristics of ATM Service ATM has several characteristics which differentiates it from current link level technologies. First of all, ATM has the capability of providing many virtual channels to transmit information over a single wire (or fiber). This is very similar to X.25, where many logical channels can be established over a single physical media. But unlike X.25, ATM allows for each of these channels or circuits to have a customizable set of performance and quality of service characteristics. Link level technologies like Ethernet provide a single channel with a single performance and quality of service characteristic. In a sense, a single ATM link level media appears like an array of of link level technologies each with customizable characteristics. ATM virtual circuits can be established dynamically utilizing its signaling protocol. ATM signaling is a source initiated negotiation process for connection establishment. This protocol informs elements in the network of the characteristics for the desired connection. ATM signaling does not provide any guidelines for how network elements decide whether it can accept a call or where a signaling request should be forwarded if the end destination (from the link level perspective) has not been reached. In short, ATM signaling does not support any routing functionality of network admission control. ATM signaling establishes a "hard state" in the network for a call. "Hard state" implies that the state of a connection in intermediate switching equipment can be set and once established it will be Brazdziunas [Page 3] INTERNET-DRAFT IPng Support for ATM Services March 1994 maintained until a message is received by one of the ends of the call requesting a change in state for the connection [2]. As a result, an ATM end system (this could be a workstation with an ATM adapter or a router with an ATM interface) receives guaranteed service from the ATM network. The ATM network is responsible for maintaining the connection state. The price the ATM termination points pay for this guarantee is the responsibility of changing the state of the connection, specifically informing the ATM network to establish, alter, or tear-down the connection. Each ATM end point in a network has an ATM address associated with it to support dynamic connection establishment via signaling. These addresses are hierarchical in structure and globally unique [3]. As a result, these addresses are routable. This allows ATM networks to eventually support a large number of ATM endpoints once a routing architecture and protocols to support it become available. The ATM User-Network Interface (UNI) signaling protocol based on ITU-TS Q.93B allows many different service parameters to be specified for describing connection characteristics. [3] These parameters can be grouped into several categories: ATM adaptation layer (AAL) information, network QOS objectives, connection traffic descriptor, and transit network selector. The AAL information specifies negotiable parameters such as AAL type and maximum packet sizes. The network QOS objectives describe the service that the ATM user expects from the network. Q.93B allows for one of five service classes to be selected by the ATM user. The service classes are defined as general traffic types such as circuit emulation (class A), variable bit rate audio and video (class B), connection-oriented data transfer (class C), connectionless data transfer (class D), best effort service (class X), and unspecified [3]. Each of these categories are further specified through network provider objectives for various ATM performance parameters. These parameters may include cell transfer delay, cell delay variation, and cell loss ratio. The connection traffic descriptor specifies characteristics of the data generated by the user of the connection. This information allows the ATM network to commit the resources necessary to support the traffic flow with the quality of service the user expects. Characteristics defined in the ATM Forum UNI specification include peak cell rate, sustainable cell rate, and maximum and minimum burst sizes [3]. Lastly, the transit network selection parameter allows an ATM user to select a preferred network provider to service the connection [3]. 5. Parameters Required to Map IPng to ATM Brazdziunas [Page 4] INTERNET-DRAFT IPng Support for ATM Services March 1994 There are several parameters required to map ATM services from a higher level service like IPng. These ATM parameters can be categorized in the following manner: addressing parameters, connection QOS-related parameters, connection management information, and ATM virtual circuit identifier. The first three categories provide support for ATM signaling. The last parameter, a connection identifier that maps IPng packets to ATM virtual circuits, provides support for an ATM virtual circuit per application when the end-to- end connection travels across an ATM subnetwork(s) (this does not assume that ATM is the only type of subnetwork that this connection travels across). Below, mapping issues for each of these parameters will be described. 5.1. Addressing ATM supports routable addresses to each ATM endpoint to facilitate the dynamic establishment of connections. These addresses need to be derived from a higher level address such as an IPng address and IPng routing information. This type of mapping is not novel. It is a mapping that is currently done for support of current IP over link technologies such as Ethernet. An IP over ATM address resolution protocol (ARP) has been described in the Internet Standard, "Classical IP over ATM" [5]. In addition, support for IP routing over large ATM networks is being worked in the IETF's "Routing over Large Clouds" working group. 5.2. Quality of Service As described in section 4, an ATM virtual circuit is established based upon a user's traffic characteristics and network performance objectives. These characteristics which include delay and throughput requirements can only be defined by the application level (at the transport level or above) as opposed to the internetworking (IPng) level. For instance, a file transfer application transferring a 100 MB file has very different link level performance requirements than a network time application. The former requires a high throughput and low error rate connection whereas the latter could perhaps be adequately serviced utilizing a best-effort service. Current IP does not provide much support for a quality of service specification and provides no support for the specification of link level performance needs by an application directly. This is due to the fact that only a single type of link level performance is available with link Brazdziunas [Page 5] INTERNET-DRAFT IPng Support for ATM Services March 1994 technologies like Ethernet. As a result, all applications over IP today receive the same level of link service. IPng packets need not explicitly contain information parameters describing an application's traffic characteristics and network performance objectives (e.g. delay = low, throughput = 10 Mb/s). This information could potentially be mapped from resource reservation protocols that operate at the IP (and potentially IPng) level [4]. 5.3. Connection Management The establishment and release of ATM connections should ultimately be controlled by the applications utilizing the circuits. As described in section 4, ATM signaling establishes a "hard state" in the network which is controlled by the ATM termination points [2]. Currently, IP provides no explicit mechanism for link level connection management. Future support for link level connection management could be accomplished through resource reservation protocols and need not necessarily be supported directly via information contained in the IPng protocol. 5.4. Connection Identifier A mapping function needs to exist between IPng packets and ATM so that application flows map one-to-one to ATM virtual circuits. Currently, application traffic flows are identified at the transport level by UDP/TCP source and destination ports and IP protocol identifiers. This level of identification should also be available at the IPng level so that information in the IPng packets identify an application's flow and map to an ATM virtual circuit supporting that flow when the IPng packets travels across an ATM subnetwork(s). Using the current IP protocol, identifying an application's traffic flow requires the combination of the following five parameters: source and destination IP addresses, source and destination UDP/TCP ports, and IP protocol identifier. This application connection identifier for IP is complex and could potentially be costly to implement in IP end stations and routers. The IPng connection identifier should be large enough so that all application level traffic from an IPng end point can be mapped into the IPng packet. Currently, ATM provides 24 bits for virtual circuit identification (VPI and VCI). This provides sufficient capacity for 2^24 Brazdziunas [Page 6] INTERNET-DRAFT IPng Support for ATM Services March 1994 (16,777,216) connections [6]. The actual number of bits that are used for the ATM virtual circuit however is established through negotiation between the ATM endpoint and ATM network. This number is useful as an upper bound for the number of mappings that are needed to be supported by IPng. An IPng candidate should be able to identify how IPng packets from an application can map to an ATM virtual circuit. In addition, this mapping should be large enough to support a mapping for every IPng application on an end system to an ATM virtual circuit. Careful consideration should be given to complexity of this mapping for IPng to ATM since it needs to eventually support gigabit/sec rates. Security Considerations Security issues are not addressed in this memo. References [1] Bradner, S., Mankin, A., "IP: Next Generation (IPng) White Paper Solicitation", RFC 1550, December, 1993. [2] Clark, D. D., "The Design Philosophy of the DARPA Internet Protocols", Proc. ATM SIGCOMM '88, August, 1988. [3] "ATM User-Network Interface Specification, Version 3.0", ATM Forum, September 10, 1993 [4] Zhang, L., Estrin, D., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Internet Draft, October, 1993. [5] Laubach, M., "Classical IP and ARP over ATM", Internet Draft, December 20, 1993. [6] "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols Generic Requirements", Bellcore Technical Advisory TA-NWT-001113, Issue 1, June 1993. [7] Cole, R.G., "IP over ATM: A Framework Document", Internet Draft, January, 1994. Brazdziunas [Page 7] INTERNET-DRAFT IPng Support for ATM Services March 1994 Author Information Christina Brazdziunas Bellcore 445 South Street Morristown, NJ 07960 (201) 829-4173 crb@faline.bellcore.com Brazdziunas [Page 8] From rcallon@pobox.wellfleet.com Mon May 23 16:57:37 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA26290 for ; Mon, 23 May 1994 17:01:33 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09454; Mon, 23 May 94 17:00:49 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA25455; Mon, 23 May 94 16:57:37 EDT Date: Mon, 23 May 94 16:57:37 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9405232057.AA25455@pobox.wellfleet> To: bound@zk3.dec.com Subject: Re: Bob Moskowitz (Chrysler) thoughts today on IPng Cc: ipng@cmf.nrl.navy.mil As a caveat I don't ever perceive IPng only routers its the hosts I am thinking about. So this is really a host only discussion. Jim; I guess that I have to ask what do you mean by this being a host-only discussion? I have heard similar opinions expressed by others in the past, that _ _ _ _ the routers and service providers, and let`s just do what the host vendors think is the best for them (after all, the hosts are by far the most numerous systems in the net). Certainly we have to be concerned with what hosts are going to do. Certainly router vendors have a long history of trying their best to be compatible with whatever hosts are doing, regardless of how reasonable or unreasonable the associated protocols are. However, if we want IPng networks to be scalale and manageable, then we have to think about the network as a whole, not just the hosts. It is not going to do the user much good if we come up with some new protocol (or transition plan) which is great from the hosts perspective, but which the public service providers (ie, Internet regionals) are not capable of managing in a large network. Isn't the whole point of IPng to make the Internet scale to a much larger size, and aren't routers and public service providers necessary if we want to accomplish this? Perhaps I have misunderstood your comment. Ross From bound@zk3.dec.com Tue May 24 00:16:59 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA28228 for ; Tue, 24 May 1994 00:22:28 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA24766; Mon, 23 May 94 21:17:07 -0700 Received: by xirtlu.zk3.dec.com; id AA26157; Tue, 24 May 1994 00:17:05 -0400 Message-Id: <9405240417.AA26157@xirtlu.zk3.dec.com> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Bob Moskowitz (Chrysler) thoughts today on IPng In-Reply-To: Your message of "Mon, 23 May 94 16:57:37 EDT." <9405232057.AA25455@pobox.wellfleet> Date: Tue, 24 May 94 00:16:59 -0400 X-Mts: smtp Ross, => As a caveat I don't ever perceive IPng only routers its the hosts => I am thinking about. So this is really a host only discussion. >Jim; >I guess that I have to ask what do you mean by this being a >host-only discussion? I have heard similar opinions expressed >by others in the past, that _ _ _ _ the routers and service >providers, and let`s just do what the host vendors think is >the best for them (after all, the hosts are by far the most >numerous systems in the net). In my statement I am saying that it could be a requirement that hosts be deployed with IPng only. I will not get into why as that could screw up me trying to respond. Then what I am saying is that I do not think routers would be requested by customers to deploy IPng only during the transition period. I do not advocate or support any myopic thinking that states we should just do what is best for hosts and all others will follow. This is not a good technical or business strategy. I have heard this too and don't agree with those who say such nonsense. This was not the jist of my mail. >Certainly we have to be concerned with what hosts are going to >do. Certainly router vendors have a long history of trying their >best to be compatible with whatever hosts are doing, regardless >of how reasonable or unreasonable the associated protocols are. When I stated its a host problem I did not mean to also imply it was a host only 'transition' problem. If my customers want IPng only then I have to give that to them. I don't tell them what they should do I just take in the requirements and if I can build the product they want and make a profit I do it, if not I don't build the product. Its very simple really. Clearly as a host vendor if we believe that we must deliver IPng only systems, then we need to 'consider' that case in the transition issue during that discussion in the IETF and the Directorate. >However, if we want IPng networks to be scalale and manageable, >then we have to think about the network as a whole, not just the >hosts. It is not going to do the user much good if we come up >with some new protocol (or transition plan) which is great from >the hosts perspective, but which the public service providers >(ie, Internet regionals) are not capable of managing in a large >network. Isn't the whole point of IPng to make the Internet >scale to a much larger size, and aren't routers and public >service providers necessary if we want to accomplish this? I agree completely. >Perhaps I have misunderstood your comment. No, I can understand your response. I hope its more clear now and its focus, context, and scope of intent. If I have to deploy IPng only systems and support IPv4/IPng for some customers on a host. I have some serious engineering design goals to meet. As Jon Crowcroft pointed out its getting to be more of a systems engineering job with IPng than a traditional engineering job. I want to work with a shared code base and a single data flow in my host kernel for IPng/IPv4. This requires me to build gadgets at the transport and data link layer. The network layer will have to support two models )--> IPng and IPv4, but the rest of my host kernel will not have to do that and can use shared code base. In other words one transport and data link layer for both IPng and IPv4, but two network layers: one for IPng and one for IPv4. Its not simple to do and requires a lot of work and about 9 man months already and its working right now. The benefits are that it makes resolving bugs in the kernel easier, less engineers to maintain the code base (many companies have OSI, IPX, IPv4, etc. protocol development groups) so an IPv4 kernel engineer is also the IPng kernel engineer for their component, and enhancements/future development of unknown additions for IPng can be better integrated. True its a large up front investment and a complex exercise in operating system component integration, but a valid software engineering approach in the 90's. Its like Ada for the application layer folks, which is a true software engineering language. You cannot hack with Ada (unless your Booch or someone like that and then only maybe), you are forced to maintain the principles of good software engineering practice, but I would not attempt to build an operating system with Ada either. Anyway if I have to support IPng only I will engineer my software for a host kernel differently than if I did not have to support IPng only, because I have chosen an integrated network layer approach as opposed to the classic dual or hybrid network polylithic approach for IPng/IPv4, as a software engineering model to build IPng prototypes. /jim From brian@dxcoms.cern.ch Tue May 24 08:18:11 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA28600 for ; Tue, 24 May 1994 02:18:44 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12070; Tue, 24 May 1994 08:18:12 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA26946; Tue, 24 May 1994 08:18:11 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405240618.AA26946@dxcoms.cern.ch> Subject: Don't miss this one To: ipng@cmf.nrl.navy.mil Date: Tue, 24 May 1994 08:18:11 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1235 I wouldn't want the Directorate to miss this one in the flood... Brian > From owner-Big-Internet@munnari.OZ.AU Tue May 24 06:01:40 1994 > X-Delivered: at request of brian on dxcoms.cern.ch > Precedence: list > Message-Id: <9405240045.AA06352@tipper.oit.unc.edu> > To: "Peter S. Ford" > Cc: francis@cactus.slab.ntt.jp (Paul Francis), J.Crowcroft@cs.ucl.ac.uk, > big-internet@munnari.oz.au > Subject: Re: NSAPs, etc > In-Reply-To: Your message of "Mon, 23 May 94 17:49:32 MST." > <199405232349.RAA20036@goshawk.lanl.gov> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Date: Mon, 23 May 94 20:45:26 -0400 > From: Simon E Spero > > If we do end up with 64bit EIDs which don't have to always double as locators, > then there is a good case to be made for grandfathering at least two schemes. > > Allocating 2^32 values to subsume the existing IP address space would make > transitioning a little easier, especially if IPNG is deployable before > IPV4 Judgment Day. > > Allocating 2^48 values to correspond to IEEE addresses would also make > sense, as if the numbers are already out there, it makes sense to use them. > > Simon > From brian@dxcoms.cern.ch Tue May 24 08:21:09 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA28610 for ; Tue, 24 May 1994 02:21:43 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12241; Tue, 24 May 1994 08:21:10 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27071; Tue, 24 May 1994 08:21:10 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405240621.AA27071@dxcoms.cern.ch> Subject: Re: Random thoughts To: ipng@cmf.nrl.navy.mil Date: Tue, 24 May 1994 08:21:09 +0200 (MET DST) In-Reply-To: <9405231546.AA16270@WC.Novell.COM> from "Greg Minshall" at May 23, 94 08:46:05 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 230 Folks, If further retreat(s) are planned please put one of them the week before Toronto and within a thousand miles or so of Toronto. Or of course in Geneva (Switzerland, not Illinois) where you would be most welcome. Brian From bound@zk3.dec.com Tue May 24 09:34:32 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA00575 for ; Tue, 24 May 1994 09:36:32 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA22134; Tue, 24 May 94 06:34:51 -0700 Received: by xirtlu.zk3.dec.com; id AA05795; Tue, 24 May 1994 09:34:38 -0400 Message-Id: <9405241334.AA05795@xirtlu.zk3.dec.com> To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: Random thoughts In-Reply-To: Your message of "Tue, 24 May 94 15:42:22 +0200." <9405240642.AA03203@cactus.slab.ntt.jp> Date: Tue, 24 May 94 09:34:32 -0400 X-Mts: smtp I think what Brian and Paul stated for Retreats is good a good idea. Just so all know I am under heavy travel restrictions now (not me personally but the company). But, thats OK I trust you all. I hope this is alleviated July 1st, but if not I am close enough to Toronto to drive from Boston, which I will probably do anyway and make a pitt stop in Montreal (directly North of my EID). Right now I think the more we can interact in person or one-on-one is really a good idea. I think the group dynamic is at a point where we can discuss and conclude issues expediently. One question I have is that if Yakov and any other Big 10 folks are now integrated into our process do we need to add them to the Directorate discussions as additions? I am not saying do it, I am just asking. Also if there is anything on the East Coast as far as a meeting I told Scott and Allison if we only get 12 folks I can host this at my house too. I have large yard with sit down type facilities in key locations for break outs too. Plus I will cook up a Detroit barbecue for ya all too and if you like spring feed lakes for swimming I have access to private beach within 8 mins. Golf is 15 minutes away. But I am one hour from Bean town. /jim From francis@cactus.slab.ntt.jp Tue May 24 15:42:22 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id CAA28686 for ; Tue, 24 May 1994 02:42:32 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 24 May 1994 15:42:22 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id PAA22062; Tue, 24 May 1994 15:42:22 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA03203; Tue, 24 May 94 15:42:22 JST Date: Tue, 24 May 94 15:42:22 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405240642.AA03203@cactus.slab.ntt.jp> To: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: Random thoughts > > Folks, > > If further retreat(s) are planned please put one of them the > week before Toronto and within a thousand miles or so of Toronto. > Or of course in Geneva (Switzerland, not Illinois) where you > would be most welcome. > Another convenient (or perhaps I should say non-pessimal) choice for me would be the week before or after INET. The location should be somewhere between Japan and Prague.... PF From sob@hsdndev.harvard.edu Sat May 28 12:01:21 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA04735 for ; Sun, 29 May 1994 16:05:08 -0400 Date: Sat, 28 May 94 12:01:21 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405281601.AA13561@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: notes from BigTen We have received a few pokes about getting out the notes from the retreat. We have been holding off on getting them out until the proposal have gone out on the mailing lists. We want to be very sure that the Working group chairs get a chance to frame the discussion before the waters get cloudy. We will send out the notes as soon as the discussions get started. Scott & Allison PS - we are narrowing down on a date that we can both make for the next retreat. From jcurran@nic.near.net Mon May 30 00:36:58 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA06481 for ; Mon, 30 May 1994 00:37:59 -0400 Received: from platinum.near.net by nic.near.net id aa03066; 30 May 94 0:37 EDT To: ipng@cmf.nrl.navy.mil Subject: Excerpt from mail regarding encoding of addresses Date: Mon, 30 May 1994 00:36:58 -0400 From: John Curran Message-ID: <9405300037.aa03066@nic.near.net> In some private mail, I found myself explaining why encoding the length specifically into the address may be good idea (and likewise why letting folks on a whim extend their addresses to the right might be a bad idea). I figured that I'd share these ponderings: ] Presume that we allow 8 and 16 byte address allocations to sites, and due ] to inefficiencies, we run out of such allocations in 40 years. If one does ] not specifically encode the length in the assignment, then anyone can extend ] their own address allocation to have 24 or 32 byte significance. (In effect, ] we will have run out of addresses, again). ] ] The best way to avoid this is to encode the length into the address, so that ] someone with a 8-byte address has _no claim_ to the similiar 16-byte or 24 ] or 32 byte prefixes. Comments welcome... /John From brian@dxcoms.cern.ch Mon May 30 08:24:35 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA06692 for ; Mon, 30 May 1994 02:25:08 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24471; Mon, 30 May 1994 08:24:36 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA23437; Mon, 30 May 1994 08:24:35 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405300624.AA23437@dxcoms.cern.ch> Subject: Re: Excerpt from mail regarding encoding of addresses To: jcurran@nic.near.net (John Curran) Date: Mon, 30 May 1994 08:24:35 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <9405300037.aa03066@nic.near.net> from "John Curran" at May 30, 94 00:36:58 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 205 John, I haven't got the slightest context to help me understand your mail. I would observe that telephone addresses are right-extensible, don't have a length field, and are somewhat widely used. Brian From lixia@parc.xerox.com Mon May 30 21:46:30 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA09576 for ; Tue, 31 May 1994 00:47:16 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14662(1)>; Mon, 30 May 1994 21:46:42 PDT Received: by redwing.parc.xerox.com id <57153>; Mon, 30 May 1994 21:46:39 -0700 Date: Mon, 30 May 1994 21:46:30 PDT Sender: Lixia Zhang From: Lixia Zhang To: John Curran Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of Sun, 29 May 1994 21:36:58 -0700 Message-ID: > In some private mail, I found myself explaining why encoding the length > specifically into the address may be good idea (and likewise why letting > folks on a whim extend their addresses to the right might be a bad idea). > > I figured that I'd share these ponderings: > > ] Presume that we allow 8 and 16 byte address allocations to sites, and due > ] to inefficiencies, we run out of such allocations in 40 years. If one does > ] not specifically encode the length in the assignment, then anyone can extend > ] their own address allocation to have 24 or 32 byte significance. (In effect, > ] we will have run out of addresses, again). > ] > ] The best way to avoid this is to encode the length into the address, so that > ] someone with a 8-byte address has _no claim_ to the similiar 16-byte or 24 > ] or 32 byte prefixes. John, The above brief statements didn't really explain why extending the addresses to the right might be bad, at least I can't see it. Rather, I see several advantages for a site to be able to extending addresses to the right, e.g. have a small address when the site is small, grow the address only when the site grows. > Comments welcome... Here's my $0.02. Lixia From bound@zk3.dec.com Tue May 31 07:41:22 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA10498 for ; Tue, 31 May 1994 07:46:14 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA02831; Tue, 31 May 94 04:41:30 -0700 Received: by xirtlu.zk3.dec.com; id AA06624; Tue, 31 May 1994 07:41:28 -0400 Message-Id: <9405311141.AA06624@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: notes from BigTen In-Reply-To: Your message of "Sat, 28 May 94 12:01:21 EDT." <9405281601.AA13561@hsdndev.harvard.edu> Date: Tue, 31 May 94 07:41:22 -0400 X-Mts: smtp >We have received a few pokes about getting out the notes from the retreat. >We have been holding off on getting them out until the proposal have >gone out on the mailing lists. We want to be very sure that the Working >group chairs get a chance to frame the discussion before the waters >get cloudy. >We will send out the notes as soon as the discussions get started. This is not a good argument to not send out the information. The minutes will serve as context. I have never heard in any committee or any group where minutes to the group were not sent out because they would prevent other work within that committee. This could be construed as invalid logic or an excuse because no one is capabable of writing up the minutes. Or a major ploy in a political bent by the leaders to move the powers that be in a particular direction, which is fair, but not the same process we have used for the last 6 months on this Directorate. >From a paper trail perspective for the IETF community it also will look better if the minutes come out before any WG coordination statements, this way the open process was recorded historically and then the effect can be seen. >PS - we are narrowing down on a date that we can both make for the >next retreat. What retreat? Why don't you throw some dates and topics out? We had a discussion regarding various mini meetings on key topics Transition being one of them which would be the only topic. /jim From bound@zk3.dec.com Tue May 31 07:58:13 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA10611 for ; Tue, 31 May 1994 08:02:16 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA03650; Tue, 31 May 94 04:58:20 -0700 Received: by xirtlu.zk3.dec.com; id AA06875; Tue, 31 May 1994 07:58:19 -0400 Message-Id: <9405311158.AA06875@xirtlu.zk3.dec.com> To: John Curran Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of "Mon, 30 May 94 00:36:58 EDT." <9405300037.aa03066@nic.near.net> Date: Tue, 31 May 94 07:58:13 -0400 X-Mts: smtp John, >In some private mail, I found myself explaining why encoding the length >specifically into the address may be good idea (and likewise why letting >folks on a whim extend their addresses to the right might be a bad idea). Encoding lengths inside of addresses is a very bad idea. Plus you have two ideas in your sentence. One encoding length in addresses and second extending addresses to the right. If we are to have good technical discussions its important we separate out ideas into clear and concise points and try to not overlap context into focused technical points. But you go first with your TECHNICAL argument. >I figured that I'd share these ponderings: >] Presume that we allow 8 and 16 byte address allocations to sites, and due >] to inefficiencies, we run out of such allocations in 40 years. If one does >] not specifically encode the length in the assignment, then anyone can extend >] their own address allocation to have 24 or 32 byte significance. (In effect, >] we will have run out of addresses, again). >] Well what about infinity do you think we can solve that problem too. Or should I ask how high is up or if there is a creator who created the creator. This kind of question in my mind causes an infinite loop. If we are to go down this path then put the address length outside of the address and devise an orderded methodology to get started and how those addresses get increased. >] The best way to avoid this is to encode the length into the address, so that >] someone with a 8-byte address has _no claim_ to the similiar 16-byte or 24 >] or 32 byte prefixes. This logic is flawed. Why is this under more control than any other scheme. It seems to me that in addition to address length we need what an NSAP calls the routing domain. This domain may define the address length. But this will only work if hosts in fact do have EIDs which are globally unique. In this manner then locators can be defined in structure by the routing domain. /jim From jcurran@nic.near.net Tue May 31 08:24:02 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA10764 for ; Tue, 31 May 1994 08:25:10 -0400 Received: from platinum.near.net by nic.near.net id aa21571; 31 May 94 8:25 EDT To: Lixia Zhang cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-reply-to: Your message of Mon, 30 May 1994 21:46:30 -0700. Date: Tue, 31 May 1994 08:24:02 -0400 From: John Curran Message-ID: <9405310825.aa21571@nic.near.net> -------- ] From: Lixia Zhang ] Subject: Re: Excerpt from mail regarding encoding of addresses ] Date: Mon, 30 May 1994 21:46:30 PDT ] > ] ] > ] The best way to avoid this is to encode the length into the address, ] > ] so that someone with a 8-byte address has _no claim_ to the similiar ] > ] 16-byte or 24 or 32 byte prefixes. ] ] John, ] ] The above brief statements didn't really explain why extending the ] addresses to the right might be bad, at least I can't see it. Apologies to all, I was definitely too terse in my description. ] Rather, I see several advantages for a site to be able to extending ] addresses to the right, e.g. have a small address when the site is ] small, grow the address only when the site grows. I acknowledge the advantage. Let me try to restate the disadvantage, with context: Presume that we have 8, 16, 24, and 32 octet addresses. I will ignore the 8 octet case for the moment, as it only serves to muddy the waters. Presume further that we create a address allocation scheme (similiar to the CIDR or SIPP allocation models) by which we assign (via delegated registries) prefixes to sites. For conveniance sake, let's say that the popular prefix size is 6 octets long, leaving the sites 4 octets worth of subnetting/areas and the lower 6 for painless autoconfiguration. If we do not allow "rightward extension", then each site is getting 2^80 worth of address space. If the site is allowed rightward extension, then they receive 2^80, 2^144, or 2^208 worth of address space. If we allow rightward extensions, then we've effectively droppped back to a 2^48 prefix space, and once those prefixes are assigned we will have allocate the entire address space. The utilization is insured of being very low. Let's hope the IANA keeps a few 16-byte site-prefixes around so we'll at least have some address space unassigned when the prefixes are depleted. /John From brian@dxcoms.cern.ch Tue May 31 14:58:41 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA11639 for ; Tue, 31 May 1994 09:17:21 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA25199; Tue, 31 May 1994 14:58:42 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA17873; Tue, 31 May 1994 14:58:41 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405311258.AA17873@dxcoms.cern.ch> Subject: Re: Excerpt from mail regarding encoding of addresses To: jcurran@nic.near.net (John Curran) Date: Tue, 31 May 1994 14:58:41 +0200 (MET DST) Cc: lixia@parc.xerox.com, ipng@cmf.nrl.navy.mil In-Reply-To: <9405310825.aa21571@nic.near.net> from "John Curran" at May 31, 94 08:24:02 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3157 When I change service provider I will change prefix. However, I cannot afford to renumber internally. (When Geneva moved from six to seven digit telephone numbers, our internal phone numbers did not change, but our external prefix changed from +41 22 83 to +41 22 767. ) If the prefix gets longer (or shorter) by N bytes, so must the full address. The conclusion is that either the address length AND prefix length are fixed, or BOTH are variable. When my site gets bigger, I need to do the same thing internally. My conclusion is that we need variable length, and we need a way to distinguish the prefix (globally administered) from the suffix (locally administered). The variable lengths should be quantised to lie on 2**N boundaries. For example: the prefix is defined to be 8, 16 or 24 bytes long. Two bits are needed to encode this. Thus 62 bits out of 64 are significant in the shortest prefix. Same rule for the suffix, subject to a maximum of 32 bytes in total if we want. This is an exsitence proof, not a proposal. John, does it overcome your objection? Brian >--------- Text sent by John Curran follows: > > -------- > ] From: Lixia Zhang > ] Subject: Re: Excerpt from mail regarding encoding of addresses > ] Date: Mon, 30 May 1994 21:46:30 PDT > ] > ] > ] > ] The best way to avoid this is to encode the length into the address, > ] > ] so that someone with a 8-byte address has _no claim_ to the similiar > ] > ] 16-byte or 24 or 32 byte prefixes. > ] > ] John, > ] > ] The above brief statements didn't really explain why extending the > ] addresses to the right might be bad, at least I can't see it. > > Apologies to all, I was definitely too terse in my description. > > ] Rather, I see several advantages for a site to be able to extending > ] addresses to the right, e.g. have a small address when the site is > ] small, grow the address only when the site grows. > > I acknowledge the advantage. > > Let me try to restate the disadvantage, with context: > > Presume that we have 8, 16, 24, and 32 octet addresses. I will ignore > the 8 octet case for the moment, as it only serves to muddy the waters. > > Presume further that we create a address allocation scheme (similiar to > the CIDR or SIPP allocation models) by which we assign (via delegated > registries) prefixes to sites. For conveniance sake, let's say that the > popular prefix size is 6 octets long, leaving the sites 4 octets worth > of subnetting/areas and the lower 6 for painless autoconfiguration. > > If we do not allow "rightward extension", then each site is getting 2^80 > worth of address space. If the site is allowed rightward extension, then > they receive 2^80, 2^144, or 2^208 worth of address space. > > If we allow rightward extensions, then we've effectively droppped back > to a 2^48 prefix space, and once those prefixes are assigned we will have > allocate the entire address space. The utilization is insured of being > very low. > > Let's hope the IANA keeps a few 16-byte site-prefixes around so we'll at > least have some address space unassigned when the prefixes are depleted. > > /John > From jcurran@nic.near.net Tue May 31 09:54:33 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA12226 for ; Tue, 31 May 1994 09:56:04 -0400 Received: from platinum.near.net by nic.near.net id aa08045; 31 May 94 9:55 EDT To: Brian.Carpenter@cern.ch cc: lixia@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-reply-to: Your message of Tue, 31 May 1994 14:58:41 +0200. <9405311258.AA17873@dxcoms.cern.ch> Date: Tue, 31 May 1994 09:54:33 -0400 From: John Curran Message-ID: <9405310955.aa08045@nic.near.net> -------- ] From: Brian Carpenter CERN-CN ] Subject: Re: Excerpt from mail regarding encoding of addresses ] Date: Tue, 31 May 1994 14:58:41 +0200 (MET DST) ] When I change service provider I will change prefix. However, ] I cannot afford to renumber internally. (When Geneva moved from ] six to seven digit telephone numbers, our internal phone numbers ] did not change, but our external prefix changed from +41 22 83 ] to +41 22 767. ) ] ] If the prefix gets longer (or shorter) by N bytes, so must the full ] address. The conclusion is that either the address length AND prefix ] length are fixed, or BOTH are variable. It may be possible that (in the Provider|Site|intra-site|Host format) in many cases the providers will be assigning sites prefixes of similiar length. Hard to tell; it's dependent on the individual provider plans. ] When my site gets bigger, I need to do the same thing internally. I disagree. You need more addresses, not necessarily related to your current assignment. ] ... ] For example: the prefix is defined to be 8, 16 or 24 bytes long. Two bits ] are needed to encode this. Thus 62 bits out of 64 are significant in ] the shortest prefix. Same rule for the suffix, subject to a maximum ] of 32 bytes in total if we want. ] ] This is an exsitence proof, not a proposal. John, does it overcome ] your objection? I believe that we're on two different topics. All I'm asserting is that if it's assumed that sites can extend their addresses to the right, then the resulting address assignments are effectively enormous, and we have the ability to serve far few sites than we might. /John From bound@zk3.dec.com Tue May 31 10:22:54 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA12937 for ; Tue, 31 May 1994 10:32:16 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA11950; Tue, 31 May 94 07:23:41 -0700 Received: by xirtlu.zk3.dec.com; id AA12571; Tue, 31 May 1994 10:23:36 -0400 Message-Id: <9405311423.AA12571@xirtlu.zk3.dec.com> To: John Curran Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of "Tue, 31 May 94 08:24:02 EDT." <9405310825.aa21571@nic.near.net> Date: Tue, 31 May 94 10:22:54 -0400 X-Mts: smtp >Presume that we have 8, 16, 24, and 32 octet addresses. I will ignore >the 8 octet case for the moment, as it only serves to muddy the waters. Why does it muddy the waters? I think this is really important to understand. It affects a building schism in the IETF which is EIDs and Locators. If all you have is an 8 octet address then whats the locator and whats the EID. I think we must have at least 16 octet addresses at a minimum for IPng. Avoiding this discussion is not good. >Presume further that we create a address allocation scheme (similiar to >the CIDR or SIPP allocation models) by which we assign (via delegated >registries) prefixes to sites. For conveniance sake, let's say that the >popular prefix size is 6 octets long, leaving the sites 4 octets worth >of subnetting/areas and the lower 6 for painless autoconfiguration. OK but I really dislike it already your not aligned and now have assumed a variable address which I reject in the context you have just proposed it. When I say not aligned your not aligned at the detail level where cache, VM buffers, and data structures must support a network address. When a packet comes in on a word(s) boundary and then must be parsed again on non-aligned word boundaries IT DOES NOT support the performance needs of the present machine architecture. Please don't think this is an acceptable compromise for those of us who believe in fixed length addresses cause it is not. >If we do not allow "rightward extension", then each site is getting 2^80 >worth of address space. If the site is allowed rightward extension, then >they receive 2^80, 2^144, or 2^208 worth of address space. I think this is too convulted and complex to deal with. Just use 8 bytes as the EID and 24 bytes as the locator. Then the locator is assigned as CIDR or with an IANA prefix. This gives you 10 x 6.27^57 routing address scope and 10 x 1.8^19 IDs for nodes. This gives you enough space. It gives you fixed length addresses at the transport. It gives you EIDs and Locators. It now needs to be tested to see if it can be routed and then managed. Bottom line you don't need variable anything. /jim From brian@dxcoms.cern.ch Tue May 31 16:33:19 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA12957 for ; Tue, 31 May 1994 10:33:56 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24283; Tue, 31 May 1994 16:33:21 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22703; Tue, 31 May 1994 16:33:19 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405311433.AA22703@dxcoms.cern.ch> Subject: Re: Excerpt from mail regarding encoding of addresses To: jcurran@nic.near.net (John Curran) Date: Tue, 31 May 1994 16:33:19 +0200 (MET DST) Cc: Brian.Carpenter@cern.ch, lixia@parc.xerox.com, ipng@cmf.nrl.navy.mil In-Reply-To: <9405310955.aa08045@nic.near.net> from "John Curran" at May 31, 94 09:54:33 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2765 >--------- Text sent by John Curran follows: > > -------- > ] From: Brian Carpenter CERN-CN > ] Subject: Re: Excerpt from mail regarding encoding of addresses > ] Date: Tue, 31 May 1994 14:58:41 +0200 (MET DST) > > ] When I change service provider I will change prefix. However, > ] I cannot afford to renumber internally. (When Geneva moved from > ] six to seven digit telephone numbers, our internal phone numbers > ] did not change, but our external prefix changed from +41 22 83 > ] to +41 22 767. ) > ] > ] If the prefix gets longer (or shorter) by N bytes, so must the full > ] address. The conclusion is that either the address length AND prefix > ] length are fixed, or BOTH are variable. > > It may be possible that (in the Provider|Site|intra-site|Host format) > in many cases the providers will be assigning sites prefixes of similiar > length. Hard to tell; it's dependent on the individual provider plans. Exactly! This should NOT be left to the providers to decide in some random way. This is exactly what was wrong with the 64-bit SIPP format. And what about people with several providers? Does their address length depend on the provider chosen for a particular transaction? > > ] When my site gets bigger, I need to do the same thing internally. > > I disagree. You need more addresses, not necessarily related to your > current assignment. I may not want MORE addresses, but just more levels of internal subnetting all of a sudden. Why should I need to talk to my providers about that? It's much better to decouple address assignments at the provider/subscriber boundary. > > ] ... > ] For example: the prefix is defined to be 8, 16 or 24 bytes long. Two bits > ] are needed to encode this. Thus 62 bits out of 64 are significant in > ] the shortest prefix. Same rule for the suffix, subject to a maximum > ] of 32 bytes in total if we want. > ] > ] This is an exsitence proof, not a proposal. John, does it overcome > ] your objection? > > I believe that we're on two different topics. All I'm asserting is that > if it's assumed that sites can extend their addresses to the right, then > the resulting address assignments are effectively enormous, and we have > the ability to serve far few sites than we might. > No, that is the topic. I am asserting that if you can find the boundary between the provider prefix and the site address, then you can extend the provider prefix when you need to, and the site can extend its addresses if it needs to, independently, up to some maximum total: Provider 2+62 bits; site 2+62, 2+126 or 2+190 bits Provider 2+126 bits; site 2+62 or 2+126 bits Provider 2+190 bits; site 2+62 bits I think this is a compromise between the old SIPP scheme and infinity. Brian From rcallon@pobox.wellfleet.com Tue May 31 10:35:09 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA13982 for ; Tue, 31 May 1994 12:55:48 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12493; Tue, 31 May 94 12:54:43 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA03207; Tue, 31 May 94 10:35:09 EDT Date: Tue, 31 May 94 10:35:09 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9405311435.AA03207@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil, jcurran@nic.near.net Subject: Re: Excerpt from mail regarding encoding of addresses ] Presume that we allow 8 and 16 byte address allocations to sites, and due ] to inefficiencies, we run out of such allocations in 40 years. If one does ] not specifically encode the length in the assignment, then anyone can extend ] their own address allocation to have 24 or 32 byte significance. (In effect, ] we will have run out of addresses, again). ] ] The best way to avoid this is to encode the length into the address, so that ] someone with a 8-byte address has _no claim_ to the similiar 16-byte or 24 ] or 32 byte prefixes. John; This leads to three obvious (closely related) questions: (i) When an organization is assigned an address prefix, does the assignment include the length bits (thus you get only one value)? (ii) Let's suppose that stateless address autoconfiguration is defined such that it works with 16 bit addresses and not with 8 bit addresses. In this case, suppose that an organization has purchased hosts from two different vendors, one of which supports stateless address autoconfiguration, and one of which doesn't. In this case, might this organization need two address assignments, one from the 8 bit space and one from the 16 bit space? (iii) When routers are forwarding based on best match routing to specific prefixes, do they ignore the length bits (for the purposes of matching addresses to prefixes), or consider the length bits to be a significant part of the address? Ross From bound@zk3.dec.com Tue May 31 10:38:01 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA13124 for ; Tue, 31 May 1994 10:50:47 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA12822; Tue, 31 May 94 07:38:12 -0700 Received: by xirtlu.zk3.dec.com; id AA13122; Tue, 31 May 1994 10:38:07 -0400 Message-Id: <9405311438.AA13122@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of "Tue, 31 May 94 14:58:41 +0200." <9405311258.AA17873@dxcoms.cern.ch> Date: Tue, 31 May 94 10:38:01 -0400 X-Mts: smtp Brian, I don't think we can have our cake and eat it too. If you have 8 bytes for your nodes or that which you want to remain the same even if the other part of the address gets renumbered. And you have a prefix for routing (24 bytes or less). And they change your prefix for some reason then your nodes should not care. Unless they also change the routing algorithm too. Another approach is this: 8byte - EID (e.g. host, router, transport ID, cluster alias). 8byte - Site Prefix ID (defined by the private network). 16byte - Routing prefix (defined by the Address Authority). EIDs and Routing Prefixes would be provided by the Address Authority. Routing to the EID would require an algorithm within interior routing protocols to hash on the private networks prefix and continue the packet within the private network. No one should care what other private networks use as site prefixes. Essentiallty the site prefix becomes a wildcard to the routing protocol once it enters the private network. So for example for someone to send mail to ABC corp from XYZ corp all they need in the DNS mapping returned is the EID and Routing prefix for that site. No variable anything is required. /jim From sob@hsdndev.harvard.edu Tue May 31 10:56:25 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA13159 for ; Tue, 31 May 1994 10:56:42 -0400 Date: Tue, 31 May 94 10:56:25 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405311456.AA00346@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: retreat & etc We are looking at holding a 2nd IPng retreate focusing on autoconfiguration, EIDs & transition over the weekend of June 25th & 26th. The meeting will be in Boston (both of us will be in Boston then). Sorry for the weekend scheduling but it works out best by quite a bit for us and the air fares are cheaper anyway. We should try and keep the non-sipp directorate involvement in the SIPP list discussions after the posting of the revised proposal to a minimum, we don't want it to look like the IPng directorare is driving a solution that would otherwise not be put forward by the SIPP people. Scott & Allison (ps - we assume that you will not be reluctant to discuss things on the IPng list ) From bound@zk3.dec.com Tue May 31 10:58:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA13256 for ; Tue, 31 May 1994 11:07:40 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA14073; Tue, 31 May 94 07:58:55 -0700 Received: by xirtlu.zk3.dec.com; id AA14162; Tue, 31 May 1994 10:58:53 -0400 Message-Id: <9405311458.AA14162@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of "Tue, 31 May 94 16:33:19 +0200." <9405311433.AA22703@dxcoms.cern.ch> Date: Tue, 31 May 94 10:58:47 -0400 X-Mts: smtp ACK: Providers should no nothing of my private network other than its routing locator. Some authority needs to manage EIDs so they are globally unique unless I can be convinced some kind of IEEE MAC address can do this which I am not right now at all. I have no issue making sure that providers have the needed space and functionality to route over the Super Information Highway (the real IPng issue from my perspective) but I do not want them to become big brother at all. They have no need to know what my private network site prefix is or will be tomorrow. I think we have spent far to much time on taking care of the provider issue and not enough time on taking care of thE need of the customers who use the network and the vendors who need to make all this perform so customers want to use it and pay for it. The issue of network management is also in need of discussion too. If we can change the IPng equation to converge to a new LIMIT and avoid infinity (or at least force a indeterminant) we can solve this problem. /jim From brian@dxcoms.cern.ch Tue May 31 17:03:39 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA13222 for ; Tue, 31 May 1994 11:04:16 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02137; Tue, 31 May 1994 17:03:40 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA23749; Tue, 31 May 1994 17:03:39 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405311503.AA23749@dxcoms.cern.ch> Subject: Re: Excerpt from mail regarding encoding of addresses To: ipng@cmf.nrl.navy.mil Date: Tue, 31 May 1994 17:03:39 +0200 (MET DST) In-Reply-To: <9405311438.AA13122@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at May 31, 94 10:38:01 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1525 Jim, Ack. You can design a fixed layout that works. I was trying to counter the assertion that you cannot design extensible addresses that work. Well, let's see what SIPP comes up with. Brian >--------- Text sent by bound@zk3.dec.com follows: > > Brian, > > I don't think we can have our cake and eat it too. > > If you have 8 bytes for your nodes or that which you want to remain the > same even if the other part of the address gets renumbered. > > And you have a prefix for routing (24 bytes or less). > > And they change your prefix for some reason then your nodes should not > care. Unless they also change the routing algorithm too. > > Another approach is this: > > 8byte - EID (e.g. host, router, transport ID, cluster alias). > 8byte - Site Prefix ID (defined by the private network). > 16byte - Routing prefix (defined by the Address Authority). > > EIDs and Routing Prefixes would be provided by the Address Authority. > > Routing to the EID would require an algorithm within interior routing > protocols to hash on the private networks prefix and continue the packet > within the private network. No one should care what other private > networks use as site prefixes. Essentiallty the site prefix becomes a > wildcard to the routing protocol once it enters the private network. > > So for example for someone to send mail to ABC corp from XYZ corp all > they need in the DNS mapping returned is the EID and Routing prefix for > that site. No variable anything is required. > > /jim > > From scoya@CNRI.Reston.VA.US Tue May 31 11:55:14 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA14037 for ; Tue, 31 May 1994 13:00:59 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07297; 31 May 94 11:55 EDT To: Scott Bradner cc: ipng@cmf.nrl.navy.mil Subject: Re: retreat & etc In-reply-to: Your message of "Tue, 31 May 94 10:56:25 EDT." <9405311456.AA00346@hsdndev.harvard.edu> Date: Tue, 31 May 94 11:55:14 -0400 From: Steve Coya Message-ID: <9405311155.aa07297@IETF.CNRI.Reston.VA.US> Deb, >> Please move the following files into /home/dlegare/minutes: >> >> avt-minu.tex >> area.tra >> dlsw-min.tex >> dnsfutur.tex >> uri-minu.tex >> sipp-min.tex >> >> You can move them in as the above names. Done. >> Please leave the rest of the stuff in there, unless it is taking up >> too much room and you need the laptop for something else. I might >> want to take it home again this week. Assuming that is ok with you. No problem with disk space or you're using the machine again. >> I would like to talk to you about VP Gore's letter. Do you have a >> "clean" copy (other than a fax copy)? Might not look too good if we >> don't have the original. No, all I have is a copy of the fax. Let's get it scanned and check out the results... if it looks bad (unreadable), we won't use it. Steve From Greg_Minshall@Novell.COM Tue May 31 09:05:07 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA13683 for ; Tue, 31 May 1994 12:08:38 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA17393; Tue, 31 May 94 10:07:37 MDT Received: from [130.57.64.149] by WC.Novell.COM (4.1/SMI-4.1) id AA10455; Tue, 31 May 94 09:05:12 PDT Date: Tue, 31 May 94 09:05:07 PDT Message-Id: <9405311605.AA10455@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: The Importance of Being EID Cc: ipng@cmf.nrl.navy.mil Jim, >Providers should no nothing of my private network other than its routing >locator. Some authority needs to manage EIDs so they are globally >unique unless I can be convinced some kind of IEEE MAC address can do >this which I am not right now at all. I don't believe in EIDs. I don't think anyone knows what semantics they mean when they say EIDs. I do believe in "locator == id", which is to say, something like IPv4 addresses which serve the (overloaded!) function of being something which *can* be used to get a packet to a destination; can be the parameter of gethostbyaddr(); and *can* be used by transport protocols trying to lookup connections. (You might look at the Yakov Rekhter/Peter Ford paper which, in some sense, also argues against EIDs when they make the point that a packet should be able to be dropped down anywhere, after having flowed through some number of source routes/encapsulation steps, and find its way home.) Now, there may be some issue of "locator == id" not relating enough to the hierarchical structure of the network. That seems hard. There are also issues of, say, provider selection. These latter can be dealt with using concatenation-on-left/source-routes/encapsulation. Greg From rcallon@pobox.wellfleet.com Tue May 31 12:18:58 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA13993 for ; Tue, 31 May 1994 12:56:56 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12719; Tue, 31 May 94 12:55:53 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA06999; Tue, 31 May 94 12:18:58 EDT Date: Tue, 31 May 94 12:18:58 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9405311618.AA06999@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses Regarding extending address on the right versus on the left, and regarding how large an address needs to be, I think that we need to be careful to keep in mind why we were proposing variable length addresses in the first place. There is a lot of disagreement regarding whether 8 bytes is enough for an *address*. There seem to be at least three possible ways that folks might think of using more than 8 bytes: - To aid in serverless and/or stateless address autoconfiguration. [create an address for a host based on a prefix which is already assigned to the network or area to which it attaches, plus an ID which is already assigned to the host -- eg this ensures that if I take my laptop around the world on a month-long trip, then when I return I will get the same address, even if no server at the home site was maintaining state about this system]. - To aid in address configuration and administration. For example, if a small site gets a long prefix, starts assigning addresses, and then discovers that it has run out due to rapid growth, it might extend the address on the right. - As a sort of "poor man's source routing". The latter reason seems to be largely a response to source routing being borderline unuseable in IP (and borderline or worse in CLNP). However, the proposal from the retreat to use a pointer plus a list of addresses (the first being the source, the last being the destination, any intermediate addresses, if present, specifying a source route), seems to provide a very good way to do source routing. Thus with this improved method for "real" source routing in the packets it is reasonable to require that hosts and routers both support source routing properly. This eliminates the need to use long addresses to provide "poor man's source routing". Thus we seem to be left with the first two reasons to want addresses longer than 8 bytes. Both of these imply addresses which are extended on the right (and not on the left). The first of these provides (in my opinion) a strong reason for wanting 16 byte addresses. Is there some other reason that folks may need to extend addresses on the left? Is there a concern that the high order part of the address might have to be "adjusted" even in length, due to provider hierarchies changing? Ross From scoya@CNRI.Reston.VA.US Tue May 31 13:08:33 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA14295 for ; Tue, 31 May 1994 13:26:14 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09028; 31 May 94 13:08 EDT To: ipng@cmf.nrl.navy.mil Subject: Re: retreat & etc In-reply-to: Your message of "Tue, 31 May 94 11:55:14 EDT." Date: Tue, 31 May 94 13:08:33 -0400 From: Steve Coya Message-ID: <9405311308.aa09028@IETF.CNRI.Reston.VA.US> Sorry for the glitch.... I obviously replied to the wrong envelope! Steve From smb@research.att.com Tue May 31 13:11:22 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA14159 for ; Tue, 31 May 1994 13:13:00 -0400 From: smb@research.att.com Message-Id: <199405311713.NAA14159@picard.cmf.nrl.navy.mil> Received: by gryphon; Tue May 31 13:11:22 EDT 1994 To: Scott Bradner Subject: Re: retreat & etc cc: ipng@cmf.nrl.navy.mil Date: Tue, 31 May 94 13:11:22 EDT I confess that I'm not at all enthusiastic about a weekend retreat. (Apart from that, for personal reasons the dates you've suggested are seriously pessimal for me; I'll almost certainly miss at least one day.) From lixia@parc.xerox.com Tue May 31 10:29:35 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA14333 for ; Tue, 31 May 1994 13:30:30 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14514(4)>; Tue, 31 May 1994 10:29:52 PDT Received: by redwing.parc.xerox.com id <57153>; Tue, 31 May 1994 10:29:46 -0700 Date: Tue, 31 May 1994 10:29:35 PDT Sender: Lixia Zhang From: Lixia Zhang To: ipng@cmf.nrl.navy.mil Subject: Re: retreat & etc In-Reply-To: Your message of Tue, 31 May 1994 10:11:22 -0700 Message-ID: > I confess that I'm not at all enthusiastic about a weekend retreat. I don't think I'm more enthusiastic about a weekend retreat, but given our travel budget and the soaring air fare, a weekend trip is all I can afford, unless others are willing to have it on west coast (in which case PARC would be happy to host:-) Lixia From ddc@caraway.lcs.mit.edu Tue May 31 13:35:15 1994 Return-Path: ddc@caraway.lcs.mit.edu Received: from caraway.lcs.mit.edu (CARAWAY.LCS.MIT.EDU [18.26.0.170]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA14373 for ; Tue, 31 May 1994 13:36:15 -0400 Received: by caraway.lcs.mit.edu id AA17084; Tue, 31 May 94 13:35:16 -0400 Message-Id: <9405311735.AA17084@caraway.lcs.mit.edu> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: retreat & etc In-Reply-To: Your message of Tue, 31 May 94 10:56:25 -0400. <9405311456.AA00346@hsdndev.harvard.edu> From: David Clark Date: Tue, 31 May 94 13:35:15 -0400 Sender: ddc@caraway.lcs.mit.edu X-Mts: smtp I HATE weekend meetings. NOT NICE. FORMAL PROTEST!!@#$% Dave From bound@zk3.dec.com Tue May 31 14:04:06 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA14820 for ; Tue, 31 May 1994 14:15:40 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA26070; Tue, 31 May 94 11:04:25 -0700 Received: by xirtlu.zk3.dec.com; id AA18953; Tue, 31 May 1994 14:04:12 -0400 Message-Id: <9405311804.AA18953@xirtlu.zk3.dec.com> To: Greg Minshall Cc: ipng@cmf.nrl.navy.mil Subject: Re: The Importance of Being EID In-Reply-To: Your message of "Tue, 31 May 94 09:05:07 PDT." <9405311605.AA10455@WC.Novell.COM> Date: Tue, 31 May 94 14:04:06 -0400 X-Mts: smtp Greg, >I don't believe in EIDs. I don't think anyone knows what semantics they >mean when they say EIDs. An EID is Xbytes. Its the address in transport headers. Its the key used to get a hostname from DNS. An EID has no routing context and is not routable without a locator. Its a transport ID. See NIMROD for modern explanation. Now semantics as part of IPng and the network protocol is something we would have to work on. I sent you Steve's mail on the different models using SIPP to explain EIDs was this not helpful? How about this: EID | Site Prefix | Routing Domain ---------------------------------------------------------------------- | 8 bytes | 8 bytes | 16 bytes ---------------------------------------------------------------------- The site prefix and routing domain are locators. EIDs and Routing Domain are authoritative from some place like IANA. Autoconfig uses EID and Site Prefix. If you go mobile you keep your EID but not your site prefix as one example. Locators are attached to the packet at the network layer and not needed at all at the transport layer, as source route strategy, and could have been part of the DNS record too. If you don't get where this is going I am not sure your going to be convinced and thats just the way it is. I will stop for now. >I do believe in "locator == id", which is to say, something like IPv4 >addresses which serve the (overloaded!) function of being something which >*can* be used to get a packet to a destination; can be the parameter of >gethostbyaddr(); and *can* be used by transport protocols trying to lookup >connections. Well right now I don't belive that IDs should be overloaded. This is where Yakov and I disagree on EIDs fyi, if you have seen his mail or talked to him. >(You might look at the Yakov Rekhter/Peter Ford paper which, in some sense, >also argues against EIDs when they make the point that a packet should be >able to be dropped down anywhere, after having flowed through some number >of source routes/encapsulation steps, and find its way home.) In some sense??? Thats a bit sketchy for that paper which I have read and also know that Peter and Yakov are both in tune with EIDs as a computer science model for which we have talked at length. I don't see this in the paper at all. What I see is the source route issue which is transparent to EIDs. I don;t believe they believe in my very strict model of an EID but they do understand it they just don't agree, this I can deal with. >Now, there may be some issue of "locator == id" not relating enough to the >hierarchical structure of the network. That seems hard. There are also >issues of, say, provider selection. These latter can be dealt with using >concatenation-on-left/source-routes/encapsulation. I have no problem at all with the PIP or now SIPP idea of source routing and agree with it completely. I just want an EID that contains no routing state. Its just the identifying address. /jim From rcallon@pobox.wellfleet.com Tue May 31 14:37:04 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA15130 for ; Tue, 31 May 1994 14:41:35 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA14314; Tue, 31 May 94 14:40:10 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA10140; Tue, 31 May 94 14:37:05 EDT Date: Tue, 31 May 94 14:37:04 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9405311837.AA10140@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: retreat & etc We are looking at holding a 2nd IPng retreate focusing on autoconfiguration, EIDs & transition over the weekend of June 25th & 26th. The meeting will be in Boston (both of us will be in Boston then). Sorry for the weekend scheduling but it works out best by quite a bit for us and the air fares are cheaper anyway. These dates are fine for me. A late start Saturday (10:30) would be preferable. Ross PS: I will try to take off the Friday before, in order to feel like I am having at least a little bit of weekend :-). From bound@zk3.dec.com Tue May 31 14:59:30 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA15360 for ; Tue, 31 May 1994 15:03:44 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA29586; Tue, 31 May 94 11:59:40 -0700 Received: by xirtlu.zk3.dec.com; id AA20553; Tue, 31 May 1994 14:59:36 -0400 Message-Id: <9405311859.AA20553@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: SIPP Mail went out Date: Tue, 31 May 94 14:59:30 -0400 X-Mts: smtp The mail went out if your not on the SIPP list. The mail referenced IPng minutes coming and the tech reviews too. thanks /jim From pvm@ISI.EDU Tue May 31 12:26:45 1994 Return-Path: pvm@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA15556 for ; Tue, 31 May 1994 15:31:19 -0400 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 31 May 1994 12:29:26 -0700 Message-Id: <199405311929.AA07114@zephyr.isi.edu> To: Steve Coya Cc: Scott Bradner , ipng@cmf.nrl.navy.mil Reply-To: pvm@ISI.EDU Subject: Re: retreat & etc In-Reply-To: Your message of Tue, 31 May 1994 11:55:14 -0400. <9405311155.aa07297@IETF.CNRI.Reston.VA.US> Date: Tue, 31 May 94 12:26:45 PDT From: Paul Mockapetris > >> I would like to talk to you about VP Gore's letter. Do you have a > >> "clean" copy (other than a fax copy)? Might not look too good if we > >> don't have the original. I have the original. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From lixia@parc.xerox.com Tue May 31 12:29:22 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA15551 for ; Tue, 31 May 1994 15:30:11 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14414(5)>; Tue, 31 May 1994 12:29:30 PDT Received: by redwing.parc.xerox.com id <57153>; Tue, 31 May 1994 12:29:23 -0700 Date: Tue, 31 May 1994 12:29:22 PDT Sender: Lixia Zhang From: Lixia Zhang To: ipng@cmf.nrl.navy.mil Subject: schedule for Toronto Message-ID: Allison and Scott, It's time to book the Toronto trip and I wonder if you have a schedule for IPng related activities at Toronto IETF (e.g. is there anything scheduled on Fri?) Thanks, Lixia From pvm@ISI.EDU Tue May 31 12:32:56 1994 Return-Path: pvm@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA15584 for ; Tue, 31 May 1994 15:36:02 -0400 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 31 May 1994 12:35:37 -0700 Message-Id: <199405311935.AA07189@zephyr.isi.edu> To: Lixia Zhang Cc: ipng@cmf.nrl.navy.mil Reply-To: pvm@ISI.EDU Subject: Re: retreat & etc In-Reply-To: Your message of Tue, 31 May 1994 10:29:35 -0700. Date: Tue, 31 May 94 12:32:56 PDT From: Paul Mockapetris I could probably get ISI to host if that would be helpful. An MBONE site one place or another would probably be a good idea for those that end up not making it regardless. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From deering@parc.xerox.com Tue May 31 13:42:42 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA16251 for ; Tue, 31 May 1994 16:51:53 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14413(6)>; Tue, 31 May 1994 13:51:02 PDT Received: by skylark.parc.xerox.com via suspension id <12172>; Tue, 31 May 1994 13:50:56 -0700 Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 31 May 1994 13:42:57 -0700 To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: retreat & etc In-reply-to: sob's message of Tue, 31 May 94 07:56:25 -0800. <9405311456.AA00346@hsdndev.harvard.edu> Date: Tue, 31 May 1994 13:42:42 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May31.134257pdt.12171@skylark.parc.xerox.com> > We are looking at holding a 2nd IPng retreate focusing on autoconfiguration, > EIDs & transition over the weekend of June 25th & 26th. I'll be out of the country until the evening of the 26th, so that won't work for me. If the agenda were transition only, I wouldn't mind missing the meeting (I don't have any good ideas for transition), but if you are also going to talk about EIDs and autoconfig, I'll regret missing it. Steve From bound@zk3.dec.com Tue May 31 23:09:13 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA18274 for ; Tue, 31 May 1994 23:14:27 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA23370; Tue, 31 May 94 20:09:23 -0700 Received: by xirtlu.zk3.dec.com; id AA27781; Tue, 31 May 1994 23:09:19 -0400 Message-Id: <9406010309.AA27781@xirtlu.zk3.dec.com> To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: ipng@cmf.nrl.navy.mil Subject: Re: retreat & etc In-Reply-To: Your message of "Wed, 01 Jun 94 10:20:29 +0200." <9406010120.AA08362@cactus.slab.ntt.jp> Date: Tue, 31 May 94 23:09:13 -0400 X-Mts: smtp >> >> We are looking at holding a 2nd IPng retreate focusing on autoconfiguration, >> EIDs & transition over the weekend of June 25th & 26th. The meeting will >This selection of topics for a single meeting makes no sense to me. >EIDs and autoconfiguration are issues that are much closer to addressing >than to transition. Thus, I think that EIDs and autoconfiguration, to >the extent that they need to be discussed at all, should be discussed >at the retreat that works out the address format/packet format. >The reason I say "need to be discussed at all" is because my understanding >is that we've agreed to go with IP-style addresses, that is the same address >serves as locator and identifier, and that the address will be big enough >to hold the link address for autoconfiguration purposes. Thus, I don't think >that there is that much to discuss in the context of the IPng Directorate >decision process. (Details of autoconfiguration can be worked out at and >after July ietf.) Well first of all the decision on EIDs is not done. You and Greg find no need to pursue it but thats 2 out of 16 or whatever the count is now. And that ain't a majority Paul, in fact the way I see it you and Greg are in the minority on the IPng Directorate and in the IETF community at large regarding EIDs. I have seen more support on Big-I and on SIPP for EIDs that do not contain routing state than those who believe in the overload concept. And very few who do not want to pursue EIDs at all. So again your in the minority here and as far as I am concerned it must be a topic to finalize that discussion on the Directorate. Second if you look at transition from an address perspective and determine if we can use the existing IPv4 address as part of the IPng new address for transition then what an EID is becomes very integrated to the transition discussion. But let me tell you what I don't want to see happen. People sitting on a mountain deciding the fate of the Internet who have not been in the trenches. We need to get the people on the mountain to talk to the people that keep the wheels turning for the generator. But in this game here the people on the mountain have no more to say than the people who keep the generator running which is a good thing. This is not a monarchy. Or that big fish little fish thing like the wanna-be's in Marshalls Open System book. Thats all crap and we need to get down and dirty (a phrase from the trenches). Now if people say lets just use 16bytes and then just do like IPv4. Well that changes things a bit. Because we are back to just extending IPv4 as it was architecturally with just more space. Yes we can do more interesting things with routing, autoconfig, and system discovery but we really have not evolved. EIDs permit us to explore a new model at the transport layer and for dynamic routing (locators) that do not affect a nodes identification within the topology of the Internet or within a customers private network. I don't know of any customers that would tell me. "Jim, no I prefer that all my hosts and routers be tied to the complete network address and if you change the network then all my hosts identifiers have to change". I am beginning to think we need a customer-acid test for some of our discussion instead of I AM A ROUTING GOD AND I KNOW ALL! type of premises for conclusions. This is a sure fire way to build architecture that will either not work or not be able to be SOLD. Of course then there is the view that customers are just low class peons that know nothing and will use what we give them, which I find very distasteful and in fact stupid. One thing I did not like being taken out of SIPP was removing the ability to route only on part of an address. This was advanced thinking and I liked it technically and architecturally. Too bad I missed the meeting I would have fought very hard to not have this removed with many arguments. But I am under the impression that this did have consensus? I am glad that variable addresses are not a done deal as I think these are very bad for the networks health )---> see Dan McDonalds message to SIPP which I thought summed it up pretty good. /jim From brian@dxcoms.cern.ch Wed Jun 1 08:37:16 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA18786 for ; Wed, 1 Jun 1994 02:37:50 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23233; Wed, 1 Jun 1994 08:37:18 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21250; Wed, 1 Jun 1994 08:37:16 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406010637.AA21250@dxcoms.cern.ch> Subject: Re: Excerpt from mail regarding encoding of addresses To: rcallon@pobox.wellfleet.com (Ross Callon) Date: Wed, 1 Jun 1994 08:37:16 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <9405311618.AA06999@pobox.wellfleet> from "Ross Callon" at May 31, 94 12:18:58 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 552 Ross, > Is there some other reason that folks may need to extend > addresses on the left? Is there a concern that the high > order part of the address might have to be "adjusted" > even in length, due to provider hierarchies changing? > Yes. Providers may be created and destroyed and may merge and split. Same for countries if there is a geographical component. See the trouble with international telephone prefixes caused by the breakup of the Soviet Union and the merger of the two Germanies. Format changes at the left will be needed. Brian From brian@dxcoms.cern.ch Wed Jun 1 08:42:50 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA18795 for ; Wed, 1 Jun 1994 02:43:26 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23704; Wed, 1 Jun 1994 08:42:52 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21474; Wed, 1 Jun 1994 08:42:50 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406010642.AA21474@dxcoms.cern.ch> Subject: Re: retreat & etc To: ddc@lcs.mit.edu (David Clark) Date: Wed, 1 Jun 1994 08:42:50 +0200 (MET DST) Cc: sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil In-Reply-To: <9405311735.AA17084@caraway.lcs.mit.edu> from "David Clark" at May 31, 94 01:35:15 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 328 Folks, > I HATE weekend meetings. NOT NICE. FORMAL PROTEST!!@#$% > > Dave > Well we can all agree on that but my diary at least doesn't allow for much else this month. Let's not lose time. I plan to make an airline reservation today and I have barely enough time to get formal approval for intercontinental travel. Brian From mankin@radegond.cmf.nrl.navy.mil Wed Jun 1 04:16:58 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id EAA18994 for ; Wed, 1 Jun 1994 04:17:01 -0400 Received: from localhost.cmf.nrl.navy.mil (localhost.cmf.nrl.navy.mil [127.0.0.1]) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id EAA14719 for ; Wed, 1 Jun 1994 04:16:59 -0400 Message-Id: <199406010816.EAA14719@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost.cmf.nrl.navy.mil didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil Subject: re: schedule for Toronto Date: Wed, 01 Jun 1994 04:16:58 -0400 From: Allison J Mankin Lixia asks if we have anything booked for Friday. Here's what we set up a few weeks ago for the IPng track in Toronto--we were remiss in not passing it on sooner. No IPng on Friday this time! But note open directorate meeting just after Scott and I have spoken about the recommendations on the Monday morning. We will have that multicast. Allison Draft Agenda of the Thirtieth IETF - as of 5/4/94 7:00pm (July 25-29, 1994) MONDAY, July 25, 1994 0800-0900 IETF Registration and Continental Breakfast 0900-0930 Introductions 0930-1200 Technical Presentations o IP: Next Generation Break 1330-1530 Afternoon Sessions I IPNG Open IPNG Directorate Meeting (ngdir) (Scott Bradner/Harvard and Allison Mankin/NRL) 1530-1600 Break (Refreshments provided) 1600-1800 Afternoon Sessions II IPNG Transition and Coexistence Including Testing BOF (tacit) (Geoff Huston/AARN and Atul Bonsal/DEC) 1930-2200 Evening Sessions TUESDAY, July 26, 1994 0830-0900 Continental Breakfast 0900-0930 IETF Technical Presentations 0930-1200 Morning Sessions IPNG Simple Internet Protocol Plus WG (sipp) (Steve Deering/Xerox PARC, Paul Francis/NTT and Bob Hinden/Sun) Break 1330-1530 Afternoon Sessions I IPNG TCP/UDP over CLNP-addressed Networks WG (tuba) (Peter Ford/LANL and Mark Knopper/Ameritech) 1530-1600 Break (Refreshments provided) 1600-1800 Afternoon Sessions II IPNG Address Lifetime Expectations WG (ale) (Frank Solensky/FTP Software and Tony Li/cisco) WEDNESDAY, July 27, 1994 0830-0900 Continental Breakfast 0900-0930 Technical Presentations 0930-1200 Morning Sessions IPNG TCP/UDP over CLNP-addressed Networks WG (tuba) (Peter Ford/LANL and Mark Knopper/Ameritech) Break 1330-1530 Afternoon Sessions I IPNG Common Architecture for Next-Generation IP WG (catnip) (Vladimir Sukonnik/Process Software Corporation) 1530-1600 Break (Refreshments provided) 1600-1800 Afternoon Sessions II 1930-2200 Wednesday, July 27, 1994 - Evening Session THURSDAY, July 28, 1994 0830-0900 Continental Breakfast 0900-0930 Technical Presentations 0930-1200 Morning Sessions IPNG Simple Internet Protocol Plus WG (sipp) (Steve Deering/Xerox PARC, Paul Francis/NTT and Bob Hinden/Sun) Break 1330-1530 Afternoon Sessions I IPNG Transition and Coexistence Including Testing BOF (tacit) (Geoff Huston/AARN and Atul Bonsal/DEC) 1530-1600 Break (Refreshments provided) 1600-1700 Technical Presentations 1700-1930 Open Plenary and IESG FRIDAY, July 29, 1994 0830-0900 Continental Breakfast 0900-1200 Morning Sessions Key to Abbreviations APP Applications Erik Huizer/SURFnet and John Klensin/UNU GEN General Interest INT Internet Stev Knowles/FTP Software and Claudio Topolcic/BBN IPNG IP: Next Generation Scott Bradner/Harvard and Allison Mankin/NRL MGT Network Management Marshall T. Rose/DBC OPS Operational Requirements Scott Bradner/Harvard and Michael O'Dell/UUNET Technologies RTG Routing Joel Halpern/Network Systems SAP Service Applications TBD SEC Security Jeff Schiller/MIT TSV Transport Allison Mankin/NRL USV User Services Joyce K. Reynolds/ISI From francis@cactus.slab.ntt.jp Wed Jun 1 10:20:29 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA17865 for ; Tue, 31 May 1994 21:20:42 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Wed, 1 Jun 1994 10:20:30 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA10845; Wed, 1 Jun 1994 10:19:20 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA08362; Wed, 1 Jun 94 10:20:29 JST Date: Wed, 1 Jun 94 10:20:29 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406010120.AA08362@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: retreat & etc > > We are looking at holding a 2nd IPng retreate focusing on autoconfiguration, > EIDs & transition over the weekend of June 25th & 26th. The meeting will This selection of topics for a single meeting makes no sense to me. EIDs and autoconfiguration are issues that are much closer to addressing than to transition. Thus, I think that EIDs and autoconfiguration, to the extent that they need to be discussed at all, should be discussed at the retreat that works out the address format/packet format. The reason I say "need to be discussed at all" is because my understanding is that we've agreed to go with IP-style addresses, that is the same address serves as locator and identifier, and that the address will be big enough to hold the link address for autoconfiguration purposes. Thus, I don't think that there is that much to discuss in the context of the IPng Directorate decision process. (Details of autoconfiguration can be worked out at and after July ietf.) PF From francis@cactus.slab.ntt.jp Wed Jun 1 13:35:21 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id AAA18535 for ; Wed, 1 Jun 1994 00:39:32 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Wed, 1 Jun 1994 13:35:21 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id NAA15123; Wed, 1 Jun 1994 13:34:11 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA10701; Wed, 1 Jun 94 13:35:21 JST Date: Wed, 1 Jun 94 13:35:21 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406010435.AA10701@cactus.slab.ntt.jp> To: bound@zk3.dec.com, francis@zk3.dec.com Subject: Re: retreat & etc Cc: ipng@cmf.nrl.navy.mil > > Well first of all the decision on EIDs is not done. You and Greg find > no need to pursue it but thats 2 out of 16 or whatever the count is now. > And that ain't a majority Paul, in fact the way I see it you and Greg are > in the minority on the IPng Directorate and in the IETF community at Whoa there Jim!!! I like EIDs (certain forms of them). I've proposed them twice now, first in Landmark Routing 7 years ago (long before they became fashionable), and again in Pip. I agree that a lot of people in the Directorate like EIDs. But the simple facts are, 1) we can't agree on how they should look and what they should be used for, and 2) there is no single proposal on the table on how to do them that doesn't have problems. I'd love to use IEEE-802 like numbers for EIDs, but 802 numbers themselves are not unique and may themselves be in danger of expiring, plus there are the problems on how to retrieve unused ones. I personally see no great advantage to administratively assigned ones, though others such as John Curran disagree with me on that. However, John himself admits that there are problems administering (or maybe inverse looking-up? I'm not even sure) those numbers. > > Second if you look at transition from an address perspective and > determine if we can use the existing IPv4 address as part of the IPng > new address for transition then what an EID is becomes very integrated > to the transition discussion. Well then, since EID is clearly integrated to the address discussion, it would imply that we can't have separate meetings for transition and addressing. > really have not evolved. EIDs permit us to explore a new model at the > transport layer and for dynamic routing (locators) that do not affect > a nodes identification within the topology of the Internet or within a > customers private network. I don't know of any customers that would > >........... > > One thing I did not like being taken out of SIPP was removing the > ability to route only on part of an address. This was advanced thinking > and I liked it technically and architecturally. Too bad I missed the > meeting I would have fought very hard to not have this removed with many > arguments. But I am under the impression that this did have consensus? > For whatever reason, the group was unable to move towards "new" technology. Too many people are uncomfortable with the risks. In the ase of the ability to route on part of the address, the risk was that we are not familier with the failure modes, resulting from misconfiguration, of not parsing an address from the top down. This is reasonable and understandable. The fact is that this is an open standards process. In the absense of both a dominant proposal and dominant personalities behind that proposal, a standards process tends to produce one of two things (IMHO): 1) a standard with no technological advances, or 2) a standard with every technological advance. I think the ideal situation is a dominant proposal with dominant personalities, but lacking that, I'd prefer the no technological advances to every technological advance, as the latter has a difficult time getting off the ground.... PF From smb@research.att.com Wed Jun 1 09:36:08 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA20726 for ; Wed, 1 Jun 1994 10:57:22 -0400 From: smb@research.att.com Message-Id: <199406011457.KAA20726@picard.cmf.nrl.navy.mil> Received: by gryphon; Wed Jun 1 09:36:10 EDT 1994 To: francis@cactus.slab.ntt.jp (Paul Francis) cc: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: retreat & etc Date: Wed, 01 Jun 94 09:36:08 EDT EIDs and autoconfiguration are issues that are much closer to addressing than to transition. Thus, I think that EIDs and autoconfiguration, to the extent that they need to be discussed at all, should be discussed at the retreat that works out the address format/packet format. As I recall, the outcome of the Big 10 meeting was that we didn't know what EIDs were. More precisely, we'd identified several different kinds of EIDs, with different requirements for each; until we know what they're for, we couldn't make any decision on where they should come from. From lixia@parc.xerox.com Wed Jun 1 07:09:09 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA20373 for ; Wed, 1 Jun 1994 10:09:59 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14411(6)>; Wed, 1 Jun 1994 07:09:13 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 1 Jun 1994 07:09:11 -0700 Date: Wed, 1 Jun 1994 07:09:09 PDT Sender: Lixia Zhang From: Lixia Zhang To: John Curran Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of Tue, 31 May 1994 05:24:02 -0700 Message-ID: > If we allow rightward extensions, then we've effectively droppped back > to a 2^48 prefix space, and once those prefixes are assigned we will have > allocate the entire address space. The utilization is insured of being > very low. This was the issue I was concerned at the retreat. But after discussion with Yakov, I understand now that one can avoid this problem by having a (small) left-most field to define subspaces (didnt Yakov forwarded you a copy of my short note explaining this). If you allocate addresses of different length out of different subspaces, then each can extend to the right independently. From lixia@parc.xerox.com Wed Jun 1 07:11:40 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA20394 for ; Wed, 1 Jun 1994 10:12:43 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14539(2)>; Wed, 1 Jun 1994 07:11:54 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 1 Jun 1994 07:11:43 -0700 Date: Wed, 1 Jun 1994 07:11:40 PDT Sender: Lixia Zhang From: Lixia Zhang To: John Curran Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of Tue, 31 May 1994 06:54:33 -0700 Message-ID: > ] When my site gets bigger, I need to do the same thing internally. > > I disagree. You need more addresses, not necessarily related to your > current assignment. I think you'd want more addresses with the same prefix. Furthermore, this'd better be done internally, rather than going out to ask the address czar. From lixia@parc.xerox.com Wed Jun 1 07:20:47 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA20504 for ; Wed, 1 Jun 1994 10:21:56 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14587(8)>; Wed, 1 Jun 1994 07:21:05 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 1 Jun 1994 07:21:00 -0700 Date: Wed, 1 Jun 1994 07:20:47 PDT Sender: Lixia Zhang From: Lixia Zhang To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of Tue, 31 May 1994 07:58:47 -0700 Message-ID: > Providers should no nothing of my private network other than its routing > locator. Some authority needs to manage EIDs so they are globally > unique unless I can be convinced some kind of IEEE MAC address can do > this which I am not right now at all. If there were a free, or cheap, EID game in town I doubt anybody would reject using it (I mean, an easy to get, globally unique ID for every possible device attached to the net). But given IEEE MAC addresses cannot be unique, could you explain why we should believe that some other authority can indeed do a much better job to manage truly globaly unique EIDs? (especially when I think the case of having all toasters or light switches on the net) From bound@zk3.dec.com Wed Jun 1 12:25:23 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA21614 for ; Wed, 1 Jun 1994 12:32:44 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA22013; Wed, 1 Jun 94 09:25:43 -0700 Received: by xirtlu.zk3.dec.com; id AA11074; Wed, 1 Jun 1994 12:25:29 -0400 Message-Id: <9406011625.AA11074@xirtlu.zk3.dec.com> To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: ipng@cmf.nrl.navy.mil Subject: Re: retreat & etc In-Reply-To: Your message of "Wed, 01 Jun 94 13:35:21 +0200." <9406010435.AA10701@cactus.slab.ntt.jp> Date: Wed, 01 Jun 94 12:25:23 -0400 X-Mts: smtp Paul, Excellent response. Well I am torn between producing my EID and Transition docs right now and continue to get the SIPP code up which is looking real good, we even have the multicast system discovery SIPP packets working and some route cache done too as we have sipp now working on our internal network. Pure SIPP or IPAE across our gateways. Working on autoconfig right now. I am going to talk to Noel if he wants to define an EID with me for the Directorate. At least a definition might help. I think we can figure out what they are its using them thats the hard part. /jim From rcallon@pobox.wellfleet.com Wed Jun 1 12:36:38 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA21658 for ; Wed, 1 Jun 1994 12:40:49 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25503; Wed, 1 Jun 94 12:39:43 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA27322; Wed, 1 Jun 94 12:36:38 EDT Date: Wed, 1 Jun 94 12:36:38 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9406011636.AA27322@pobox.wellfleet> To: Brian.Carpenter@cern.ch Subject: Re: Excerpt from mail regarding encoding of addresses Cc: ipng@cmf.nrl.navy.mil > Is there some other reason that folks may need to extend > addresses on the left? Is there a concern that the high > order part of the address might have to be "adjusted" > even in length, due to provider hierarchies changing? > Yes. Providers may be created and destroyed and may merge and split. Same for countries if there is a geographical component. See the trouble with international telephone prefixes caused by the breakup of the Soviet Union and the merger of the two Germanies. Format changes at the left will be needed. Brian; I agree that there are likely to be many provider changes, especially in the near term future. Plus of course there will be a few country changes (hopefully these won't be all that common, but obviously they do occur). However, why does this require changes to the length of the high order part of the address? If the provider is specified via some high-order bits in the address, can't we leave enough unassigned values to assign to new providers, without needing to extend the length of the address? This seems to come down to how well can we anticipate the manner in which the Internet will grow. Can we assign provider prefixes in such a manner that when unanticipated changes occur, there are enough bits available to re-arrange the provider's prefixes, without having to change the *length* of the prefix assigned to any one particular customer of the provider? Ross PS: I guess that the experience with the Phone companies supports your view: If I look at how things have changed over my lifetime, there has been a lot of addition of digits on the left side, at least with respect to what I had to dial on my house's telephone. PPS: The fact that we haven't even talked much about how the Internet provider space is likely to grow is perhaps not a good sign with respect to our ability to predict the direction of future growth. From bound@zk3.dec.com Wed Jun 1 14:03:19 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA22379 for ; Wed, 1 Jun 1994 14:10:31 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA12898; Wed, 1 Jun 94 11:03:39 -0700 Received: by xirtlu.zk3.dec.com; id AA13458; Wed, 1 Jun 1994 14:03:26 -0400 Message-Id: <9406011803.AA13458@xirtlu.zk3.dec.com> To: Lixia Zhang Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of "Wed, 01 Jun 94 07:20:47 PDT." Date: Wed, 01 Jun 94 14:03:19 -0400 X-Mts: smtp >If there were a free, or cheap, EID game in town I doubt anybody would >reject using it (I mean, an easy to get, globally unique ID for every >possible device attached to the net). As I said to Paul I am going to see if Noel will help me build a short doc on the game. >But given IEEE MAC addresses cannot be unique, could you explain why we >should believe that some other authority can indeed do a much better >job to manage truly globaly unique EIDs? (especially when I think >the case of having all toasters or light switches on the net) Well with 8bytes thats 2^64th EID address space. I think we can figure out a strategy to pass out EIDs. Why could not IANA do this as it does IP today. I am concerned about toasternet too. Bigger issue is how does it change DNS: Autoconfig: System Discovery OSPF or IS-IS BGP or IDRP IPng Transition In addition we need to continue the thought pattern on transport identificaion. EIDs make this very simple. But I have only so many cycles maybe I will try to have presentation at next Retreat if I can cancel my present vacation plans which I am not sure I can, without it costing me money and irratating two young folks I know. /jim From lixia@parc.xerox.com Wed Jun 1 11:34:27 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA22604 for ; Wed, 1 Jun 1994 14:35:33 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14687(2)>; Wed, 1 Jun 1994 11:34:42 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 1 Jun 1994 11:34:30 -0700 Date: Wed, 1 Jun 1994 11:34:27 PDT Sender: Lixia Zhang From: Lixia Zhang To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of Wed, 1 Jun 1994 11:03:19 -0700 Message-ID: > >If there were a free, or cheap, EID game in town I doubt anybody would > >reject using it (I mean, an easy to get, globally unique ID for every > >possible device attached to the net). > > As I said to Paul I am going to see if Noel will help me build a > short doc on the game. Noel probably can write you his definition of EID; I'm not sure about EID management part. > >But given IEEE MAC addresses cannot be unique, could you explain why we > >should believe that some other authority can indeed do a much better > >job to manage truly globaly unique EIDs? (especially when I think > >the case of having all toasters or light switches on the net) > > Well with 8bytes thats 2^64th EID address space. I think we can figure > out a strategy to pass out EIDs. Why could not IANA do this as it does > IP today. I am concerned about toasternet too. The size of the EID space is an issue but a simple one. Personally I'm more concerned with EID distribution, and more so with enforcement--how could one assure that every device, however big or small, will have a valid EID from the authority (isn't that's why IEEE MAC addresses not being unique). From lixia@parc.xerox.com Wed Jun 1 12:06:41 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA22961 for ; Wed, 1 Jun 1994 15:08:45 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14718(4)>; Wed, 1 Jun 1994 12:06:55 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 1 Jun 1994 12:06:49 -0700 Date: Wed, 1 Jun 1994 12:06:41 PDT Sender: Lixia Zhang From: Lixia Zhang To: ipng@cmf.nrl.navy.mil Subject: Re: Excerpt from mail regarding encoding of addresses In-Reply-To: Your message of Wed, 1 Jun 1994 11:34:27 -0700 Message-ID: > > >But given IEEE MAC addresses cannot be unique, could you explain why we > > >should believe that some other authority can indeed do a much better > > >job to manage truly globaly unique EIDs? (especially when I think > > >the case of having all toasters or light switches on the net) > > > > Well with 8bytes thats 2^64th EID address space. I think we can figure > > out a strategy to pass out EIDs. Why could not IANA do this as it does > > IP today. I am concerned about toasternet too. > > The size of the EID space is an issue but a simple one. > Personally I'm more concerned with EID distribution, and more so with > enforcement--how could one assure that every device, however big or > small, will have a valid EID from the authority (isn't that's > why IEEE MAC addresses not being unique). Reading my own msg I see one point is missing: I believe address management is somewhat different from EIDs (by whatever definition, independent from address), i.e. much easier enforcement. A box probably wont get its data if it doesn't have a valid address. From brian@dxcoms.cern.ch Thu Jun 2 08:09:06 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA27920 for ; Thu, 2 Jun 1994 02:09:39 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00268; Thu, 2 Jun 1994 08:09:06 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA00235; Thu, 2 Jun 1994 08:09:06 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406020609.AA00235@dxcoms.cern.ch> Subject: Provider space [was: Re: Excerpt from mail...] To: rcallon@pobox.wellfleet.com (Ross Callon) Date: Thu, 2 Jun 1994 08:09:06 +0200 (MET DST) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil In-Reply-To: <9406011636.AA27322@pobox.wellfleet> from "Ross Callon" at Jun 1, 94 12:36:38 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1307 >--------- Text sent by Ross Callon follows: ... > This seems to come down to how well can we anticipate the manner > in which the Internet will grow. Can we assign provider prefixes > in such a manner that when unanticipated changes occur, there are > enough bits available to re-arrange the provider's prefixes, > without having to change the *length* of the prefix assigned to > any one particular customer of the provider? > > Ross > > PS: I guess that the experience with the Phone companies supports > your view: If I look at how things have changed over my lifetime, > there has been a lot of addition of digits on the left side, at > least with respect to what I had to dial on my house's telephone. > > PPS: The fact that we haven't even talked much about how the > Internet provider space is likely to grow is perhaps not a good > sign with respect to our ability to predict the direction of > future growth. > You got it! Well, if you assume 256 countries or regions each hosting 256 service providers, even two bytes of provider space used efficiently is OK. E.164 tries to do it with one, two or three decimal digits which is MUCH tighter. Probably I am worrying too much. Can we be very simple minded? 4 bytes provider ID, 4 bytes subscriber locator, 8 bytes host locator? Brian From brian@dxcoms.cern.ch Thu Jun 2 08:50:44 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA28058 for ; Thu, 2 Jun 1994 02:51:19 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06267; Thu, 2 Jun 1994 08:50:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02286; Thu, 2 Jun 1994 08:50:44 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406020650.AA02286@dxcoms.cern.ch> Subject: Re: Provider space [was: Re: Excerpt from mail...] To: ipng@cmf.nrl.navy.mil Date: Thu, 2 Jun 1994 08:50:44 +0200 (MET DST) In-Reply-To: <9406020623.AA22783@cactus.slab.ntt.jp> from "Paul Francis" at Jun 2, 94 03:23:34 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1730 Paul, > > > > Can we be very simple minded? 4 bytes provider ID, 4 bytes subscriber > > locator, 8 bytes host locator? > > > > One point is that this list is missing the subnet ID, but I think > your point is that perhaps we should be setting the boundaries at > fixed and easy-to-comprehend places. Yes, exactly. > > I believe that we should not fix boundaries, and that we should only I see a big problem in variable boundaries. They increase the amount of manual configuration of routers and even hosts. They increase the complexity of the task of the allocation authorities. They make life impossible when using several service providers or changing service providers. Therefore they lead to operational problems. > specify what is assigned at the high and low ends of the address (the > high end has the provider ID, the low end the host ID). We should > give some very strong guidelines, like, don't assign any explicit > fields that are not directly related to topology, and try to leave > reserved space in between assigned values (see SIPP addr assignment > spec for example of this). We should also give example layouts for > common cases. But otherwise, we should not overly constrain the > address. > I have to argue against myself about the "8 bytes host locator". The format of this might well be site dependent (different subnetting policies, NSAP mappings, etc.). However this confines the configuration and allocation issues to a single site. My strongest feeling is that I don't want anything difficult to happen when I change service provider. if I get 8 bytes to myself from one service provider, I MUST get 8 bytes from the next one too. Anything else is an operational catastrophe. Brian From francis@cactus.slab.ntt.jp Thu Jun 2 10:12:00 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp ([192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA26690 for ; Wed, 1 Jun 1994 21:16:08 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Thu, 2 Jun 1994 10:12:00 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id KAA09132; Thu, 2 Jun 1994 10:10:49 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA18581; Thu, 2 Jun 94 10:12:00 JST Date: Thu, 2 Jun 94 10:12:00 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406020112.AA18581@cactus.slab.ntt.jp> To: bound@zk3.dec.com, francis@zk3.dec.com Subject: Re: retreat & etc Cc: ipng@cmf.nrl.navy.mil > gateways. Working on autoconfig right now. I am going to talk to Noel > if he wants to define an EID with me for the Directorate. At least a > definition might help. I think we can figure out what they are its > using them thats the hard part. > A definition would help. However, since we know that there are many possible definintions, a good taxonomy (ala what Steve did before bigTen) followed by, say, yours and Noel's prefered definitions, would help even more. PF From francis@cactus.slab.ntt.jp Thu Jun 2 15:23:34 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id CAA27991 for ; Thu, 2 Jun 1994 02:23:44 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Thu, 2 Jun 1994 15:23:34 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id PAA16377; Thu, 2 Jun 1994 15:22:22 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA22783; Thu, 2 Jun 94 15:23:34 JST Date: Thu, 2 Jun 94 15:23:34 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406020623.AA22783@cactus.slab.ntt.jp> To: Brian.Carpenter@cern.ch, rcallon@pobox.wellfleet.com Subject: Re: Provider space [was: Re: Excerpt from mail...] Cc: ipng@cmf.nrl.navy.mil > > Can we be very simple minded? 4 bytes provider ID, 4 bytes subscriber > locator, 8 bytes host locator? > One point is that this list is missing the subnet ID, but I think your point is that perhaps we should be setting the boundaries at fixed and easy-to-comprehend places. I believe that we should not fix boundaries, and that we should only specify what is assigned at the high and low ends of the address (the high end has the provider ID, the low end the host ID). We should give some very strong guidelines, like, don't assign any explicit fields that are not directly related to topology, and try to leave reserved space in between assigned values (see SIPP addr assignment spec for example of this). We should also give example layouts for common cases. But otherwise, we should not overly constrain the address. PF From brian@dxcoms.cern.ch Fri Jun 3 08:28:05 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA06755 for ; Fri, 3 Jun 1994 02:28:39 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24955; Fri, 3 Jun 1994 08:28:07 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10454; Fri, 3 Jun 1994 08:28:06 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406030628.AA10454@dxcoms.cern.ch> Subject: Re: IMPORTANT: IPng Retreat To: mankin@cmf.nrl.navy.mil (Allison J Mankin) Date: Fri, 3 Jun 1994 08:28:05 +0200 (MET DST) Cc: ipng@radegond.cmf.nrl.navy.mil In-Reply-To: <199406021801.OAA02234@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Jun 2, 94 02:01:50 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 525 This is a PAIN. I have no idea whether I can get the flights I would need; it was already difficult to get them three days ago for the Sat-Sun meeting. The probable result of changing it is that I can't come. Since this is Friday and I won't hear from you until the afternoon, I suppose I have to beg and plead with the travel agent to hold reservations on some different flights as well. But, folks, you CANNOT schedule meetings involving international participants with limited travel budgets at 3 week's notice. Brian From brian@dxcoms.cern.ch Fri Jun 3 12:48:07 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id GAA07269 for ; Fri, 3 Jun 1994 06:49:20 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23159; Fri, 3 Jun 1994 12:48:08 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19616; Fri, 3 Jun 1994 12:48:08 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406031048.AA19616@dxcoms.cern.ch> Subject: re An Architecture for BigTen Address Allocation To: ipng@cmf.nrl.navy.mil, tli@cisco.com, yakov@watson.ibm.com Date: Fri, 3 Jun 1994 12:48:07 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3001 Folks, I like "An Architecture for BigTen Address Allocation" I have one global point: Nothing must happen to my internal addressing scheme when I change service provider, or if my corporate network is multi-homed on several service providers. As far as I can see this imposes a constraint that it must be possible to distinguish the prefix from the rest of the address by inspection. The simplest answer is to have fixed sizes for the prefix and the suffix, so that if the prefix changes the suffix can always stay the same. The more complex answer is to have independently variable lengths for the prefix and the suffix. I don't have the objections to this that some people seem to have; but I can live with the simpler solution too. Now some more detailed points: > 5.4.1 Solution 1 > > One possible solution is for each multi-homed organization to obtain > its IPng address space independently from the providers to which it > is attached. **** **** You mean "of" not "from". This confused me terribly! > 5.4.2 Solution 2 ... > The second solution also requires that when external connectivity > changes, internal addresses also change. Therefore, this solution is utterly useless. I'd like to add: 5.4.4bis Solution 5 A fifth solution involves assigning multiple address prefixes to a given multi-homed organization, but treating them as equipotent; i.e., every host in the organization can be reached by using any of these prefixes. The choice of prefix in a particular case would be a matter of practicality or policy. Thus each router between MBII and the outside world would be reached by a particular prefix, but the routing inside MBII would be completely insensitive to the prefix. MBII's DNS announcements would reflect the practical or policy decisions made by MBII about which prefix is preferred for reaching a particular set of hosts. Different announcements could be made in different parts of the world??? [etc Tony, Yakov, ??] > 5.6 Zero-Homed Routing Domains ... > However, it is important that zero-homed routing domains use valid > globally unique IPng addresses. Suppose that the zero-homed routing > domain is connected through a private link to a routing domain. > Further, this routing domain participates in an internet that > subscribes to the global IPng addressing plan. This domain must be > able to distinguish between the zero-homed routing domain's IPng > addresses and any other IPng addresses that it may need to route to. > The only way this can be guaranteed is if the zero-homed routing > domain uses globally unique IPng addresses. Couldn't they use a globally defined IPng prefix which says "This is a locally defined address"? If they later join the Internet the prefix would be changed to a real one. > 5.7 Continental aggregation You don't discuss the case of intercontinental corporate networks. (IMHO they need to be multihomed according to my suggestion above). Brian From brian@dxcoms.cern.ch Fri Jun 3 12:58:33 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id GAA07293 for ; Fri, 3 Jun 1994 06:59:40 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26742; Fri, 3 Jun 1994 12:58:34 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19884; Fri, 3 Jun 1994 12:58:33 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406031058.AA19884@dxcoms.cern.ch> Subject: re BigTen Address Format Selectors and Preferred Address Formats To: ipng@cmf.nrl.navy.mil, tli@cisco.com, yakov@watson.ibm.com Date: Fri, 3 Jun 1994 12:58:33 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1442 Folks, "BigTen Address Format Selectors and Preferred Address Formats" makes me uneasy. I don't think we should mess with 8 byte addresses. They are too small. I'm not biased against extensible addresses, but the SIPP list shows that plenty of people are. I think we have to wait for the SIPP people to make a proposal. On specifics: > Bits 1 through 3 - Length (in multiple of 8 octets) Why not say "Length -1" ? That gives you up to 64 bytes! What is an IPAFS? You use a different name in #2. > 3.2 Global BigTen Unicast Addrresses with embedded IEEE 802 addresses > > > For BigTen addresses with length of 16 octets and IPAFS = 0100 (in > binary) this document defines the following format: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 001 | 0010 | Registry ID | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Firstly 0100 is listed as IANA-reserved earlier in the draft. Secondly, your diagram (and the following ones) shows length 8 bytes and IPAFS 0010. ... > The lower order 6 octets of the BigTen address contain IEEE 802 > globally administered addresses. stored in IEEE 802 canonical bit order From tli@cisco.com Fri Jun 3 10:07:54 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id NAA10396 for ; Fri, 3 Jun 1994 13:08:33 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA16457; Fri, 3 Jun 1994 10:07:54 -0700 Date: Fri, 3 Jun 1994 10:07:54 -0700 From: Tony Li Message-Id: <199406031707.KAA16457@lager.cisco.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, tli@cisco.com, yakov@watson.ibm.com In-Reply-To: Brian Carpenter CERN-CN's message of Fri, 3 Jun 1994 12:58:33 +0200 (MET DST) <9406031058.AA19884@dxcoms.cern.ch> Subject: re BigTen Address Format Selectors and Preferred Address Formats Brian, "BigTen Address Format Selectors and Preferred Address Formats" makes me uneasy. I don't think we should mess with 8 byte addresses. They are too small. I'm not biased against extensible addresses, but the SIPP list shows that plenty of people are. There are actually legit uses for 8 byte addresess. For example, there are a very large number of private IP networks, not connected to the Internet that do not need 16 byte addresses. In fact, they could easily get by with IPv4 and 4 byte addresses. However, they use off-the-shelf equipment and will undoubtedly have IPng on their network as well. As long as the transition from 8 byte to longer addresses is relatively painless, I'm not sure I see the problem. I think we have to wait for the SIPP people to make a proposal. With all due respect, may I suggest that given the mail on the SIPP mailing list that you not hold your breath. On specifics: > Bits 1 through 3 - Length (in multiple of 8 octets) Why not say "Length -1" ? That gives you up to 64 bytes! That would also be acceptable. There are a number of different implementation tradeoffs here. We chose the current alternative so that we could shift, mask and add to find the next address. What is an IPAFS? You use a different name in #2. Whoops. My fault. That's a typographical error. It should be a "LF" everywhere. > 3.2 Global BigTen Unicast Addrresses with embedded IEEE 802 addresses > > > For BigTen addresses with length of 16 octets and IPAFS = 0100 (in > binary) this document defines the following format: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 001 | 0010 | Registry ID | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Firstly 0100 is listed as IANA-reserved earlier in the draft. Secondly, your diagram (and the following ones) shows length 8 bytes and IPAFS 0010. ... Fixed. All should be LF 0001 > The lower order 6 octets of the BigTen address contain IEEE 802 > globally administered addresses. stored in IEEE 802 canonical bit order Thanks, good point. Tony From tli@cisco.com Fri Jun 3 10:35:43 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id NAA10690 for ; Fri, 3 Jun 1994 13:36:25 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA18746; Fri, 3 Jun 1994 10:35:43 -0700 Date: Fri, 3 Jun 1994 10:35:43 -0700 From: Tony Li Message-Id: <199406031735.KAA18746@lager.cisco.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, tli@cisco.com, yakov@watson.ibm.com In-Reply-To: Brian Carpenter CERN-CN's message of Fri, 3 Jun 1994 12:48:07 +0200 (MET DST) <9406031048.AA19616@dxcoms.cern.ch> Subject: re An Architecture for BigTen Address Allocation Brian, I have one global point: Nothing must happen to my internal addressing scheme when I change service provider, or if my corporate network is multi-homed on several service providers. As far as I can see this imposes a constraint that it must be possible to distinguish the prefix from the rest of the address by inspection. On an architectural level, I'm not sure I agree with this requirement. When you change providers, you will end up changing prefixes. I don't think that anything with topological sensitivity can change this. The interesting case is if you change to a longer prefix. If your existing internal addressing scheme still fits within the bounds of your previous address length and perhaps you lose some unused reserved bits within your prior addressing scheme, then you have a trivial isomorphism (e.g., take out byte 10, shift our internal addresses right one byte). If you can't fit, then yes, you're forced to a longer address length. But you now have enough space so that you again have a trivial isomorphism (e.g., shift our internal addresses right 8 bytes). Now some more detailed points: > 5.4.1 Solution 1 > > One possible solution is for each multi-homed organization to obtain > its IPng address space independently from the providers to which it > is attached. **** **** You mean "of" not "from". This confused me terribly! Fixed. Cross-pond linguistic differences, I think. ;-) > 5.4.2 Solution 2 ... > The second solution also requires that when external connectivity > changes, internal addresses also change. Therefore, this solution is utterly useless. If you believe that, then you must certainly object to section 5.2 (leaf domains). Leaf domians also have a prefix change when external connectivity changes. I'd like to add: 5.4.4bis Solution 5 A fifth solution involves assigning multiple address prefixes to a given multi-homed organization, but treating them as equipotent; i.e., every host in the organization can be reached by using any of these prefixes. The choice of prefix in a particular case would be a matter of practicality or policy. Thus each router between MBII and the outside world would be reached by a particular prefix, but the routing inside MBII would be completely insensitive to the prefix. You don't really mean that. You mean that the topology for layers under the assigned prefixes is identical with identical suffix assignments. Being completely insensitive to the prefix implies that you could never get out of the domain. ;-( MBII's DNS announcements would reflect the practical or policy decisions made by MBII about which prefix is preferred for reaching a particular set of hosts. Different announcements could be made in different parts of the world??? [etc Tony, Yakov, ??] Interesting. This is almost identical to something that Paul Francis proposed some time ago, assigning a host an address for each possible policy class. I'll think on this for a bit.... > 5.6 Zero-Homed Routing Domains ... > However, it is important that zero-homed routing domains use valid > globally unique IPng addresses. Suppose that the zero-homed routing > domain is connected through a private link to a routing domain. > Further, this routing domain participates in an internet that > subscribes to the global IPng addressing plan. This domain must be > able to distinguish between the zero-homed routing domain's IPng > addresses and any other IPng addresses that it may need to route to. > The only way this can be guaranteed is if the zero-homed routing > domain uses globally unique IPng addresses. Couldn't they use a globally defined IPng prefix which says "This is a locally defined address"? If they later join the Internet the prefix would be changed to a real one. You mean as in 5.8? Yes, they could. I'll wordsmith this and add a forward reference. > 5.7 Continental aggregation You don't discuss the case of intercontinental corporate networks. (IMHO they need to be multihomed according to my suggestion above). I guess I fail to see how intercontinental multihomed domains are a special case not covered by all of the prior multihomed domain discussion. Tony From bound@zk3.dec.com Fri Jun 3 17:03:44 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA12222 for ; Fri, 3 Jun 1994 17:08:57 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA20298; Fri, 3 Jun 94 14:03:58 -0700 Received: by xirtlu.zk3.dec.com; id AA09151; Fri, 3 Jun 1994 17:03:50 -0400 Message-Id: <9406032103.AA09151@xirtlu.zk3.dec.com> To: Tony Li Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com, bound@zk3.dec.com Subject: Re: re BigTen Address Format Selectors and Preferred Address Formats In-Reply-To: Your message of "Fri, 03 Jun 94 10:07:54 PDT." <199406031707.KAA16457@lager.cisco.com> Date: Fri, 03 Jun 94 17:03:44 -0400 X-Mts: smtp =>I think we have to wait for the SIPP people to make a proposal. >With all due respect, may I suggest that given the mail on the SIPP >mailing list that you not hold your breath. I don't agree. I am keeping the responses and there is consensus building there for the purpose Steve sent the mail out on what that list would like the IPng structure layout to be. I think it needs another week of discussion and I think we will see a core strategy and proposal. Plus the SIPP list is a valid working group and the IPng Directorate is not a working group I would like to point out. /jim From bound@zk3.dec.com Fri Jun 3 17:59:40 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA12447 for ; Fri, 3 Jun 1994 18:02:30 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA23522; Fri, 3 Jun 94 14:59:49 -0700 Received: by xirtlu.zk3.dec.com; id AA10186; Fri, 3 Jun 1994 17:59:46 -0400 Message-Id: <9406032159.AA10186@xirtlu.zk3.dec.com> To: tli@cisco.com, yakov@watson.ibm.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: re An Architecture for BigTen Address Allocation In-Reply-To: Your message of "Fri, 03 Jun 94 12:48:07 +0200." <9406031048.AA19616@dxcoms.cern.ch> Date: Fri, 03 Jun 94 17:59:40 -0400 X-Mts: smtp Tony and Yakov, Here is my input to the drafts Scott sent out. I have praise and concern. First the praise. Its a very well thought out analysis and detailed explanation of the need to use the correct architectural abstraction to gain the greatest use from an address structure and plan. It also is a wonderful tutorial on the needs of providers of network services. My concern is obviously knowing me the 'host guy' that I don't like the address format and if your watching the SIPP list I am one who will struggle with the 16byte address and then only if its fixed and no variable anything inside the address. We can get into the architectural wars at IPng Retreat or in another mail message so hear are my concerns. I can make this real simple input: 1. I do not want variable address formats that contain variable addresses within those formats. This is just to complex and not required to achieve the abstractions you request. The cost to hosts network kernels is to great and we need a much simpler plan. I will just say now 16bytes are enough for any address. 2. I don't like the idea at all of providers getting together and defining my address hierarchy. If a private company does not want to be a good citizen then they don't have to be thats free enterprise. Its been a problem for software development since our business started so I can't support this line of thinking philosophically or technically. 3. I don't see the value of registry identifiers in addresses? I think the idea in RFC1466 is a good one, but I don't see the need to take up space in the address for this function. The bottom line is the variable address strategy will not work for a host. If the objectives can be achieved with fixed addresses in this document then this would be wonderful. I cannot support this draft in its current form its unacceptable to host implementations. I know this will take a lot of discussion and I will point you to the SIPP list where this has been discussed at length. I suggest you send this draft to the SIPP list and see what response you get as there is a lot of host talent on that list. This may be a good place to iron out the issues. The basic plan is good its the way the address is structured. Also its a bit heavy on the concerns of the providers and router vendors and none on the other members of the networking paradigm. Its needs some weight in these other areas to balance it out. /jim From tli@cisco.com Fri Jun 3 15:24:41 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id SAA12531 for ; Fri, 3 Jun 1994 18:29:07 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id PAA12432; Fri, 3 Jun 1994 15:24:41 -0700 Date: Fri, 3 Jun 1994 15:24:41 -0700 From: Tony Li Message-Id: <199406032224.PAA12432@lager.cisco.com> To: bound@zk3.dec.com Cc: yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil In-Reply-To: bound@zk3.dec.com's message of Fri, 03 Jun 94 17:59:40 -0400 <9406032159.AA10186@xirtlu.zk3.dec.com> Subject: re An Architecture for BigTen Address Allocation 1. I do not want variable address formats that contain variable addresses within those formats. This is just to complex and not required to achieve the abstractions you request. The cost to hosts network kernels is to great and we need a much simpler plan. I will just say now 16bytes are enough for any address. I will simply point out that anyone who claims that 16 bytes are enough but 8 bytes weren't enough has a very difficult argument to make. Given that of the second 8 bytes, 6 are given over to IEEE addresses, you gain only two bytes of hierarcy, plus an additional level if you decide to route on the IEEE address. So you're saying that the additional 2 bytes make all of the difference in the world. Forever. I will just say now that 16 bytes are not enough for any address. As you see from our addressing plan, 16 bytes ARE enough if you only need 3 or 4 levels of hierarchy. But it is pretty clear to some of us that each level of hierarchy is necessarily sparsely populated so that you can easily accomodate growth. The result is that for an internet of more than tens of thousands of providers, with more than tens of thousands of subscribers, you need more than 16 bytes. 2. I don't like the idea at all of providers getting together and defining my address hierarchy. If a private company does not want to be a good citizen then they don't have to be thats free enterprise. Its been a problem for software development since our business started so I can't support this line of thinking philosophically or technically. I think that there's some radical misunderstanding here. The providers are responsible for providing you with a prefix. Your private company is soley responsible for defining your address hierarchy within that prefix. "It is the joint responsibility of the region, the provider and the subscriber to agree on their local addressing structure." 3. I don't see the value of registry identifiers in addresses? I think the idea in RFC1466 is a good one, but I don't see the need to take up space in the address for this function. Registry identifiers are just another topologically sensitive level of hierarchy. See the section on continental aggregation in the addressing architecture for their use. Or do you disagree with the need for continental aggregation? The bottom line is the variable address strategy will not work for a host. If the objectives can be achieved with fixed addresses in this document then this would be wonderful. The bottom line is that the variable length address strategy CAN work for hosts who are willing to code primitives to manipulate addresses. [Personally, I find that gcc provides exactly the correct facility with inline functions.] The hosts CAN easily incorporate optimizations for the profiled address lengths within the address manipulation routines. The sole question is whether or not host vendors are willing to invest now in implementing an architecture which will not need replacement within the forseeable future. So far, the answer has been no. I cannot support this draft in its current form its unacceptable to host implementations. I know this will take a lot of discussion and I will point you to the SIPP list where this has been discussed at length. I suggest you send this draft to the SIPP list and see what response you get as there is a lot of host talent on that list. This may be a good place to iron out the issues. I have two basic objections to this: first, I'm waiting for Yakov, as he's off the net for a moment and am loathe to embroil him in a flame fest without his approval. Second, I fail to see what can be gained by doing this. It's very clear from your own response that this is very much a religious issue. It's pretty clear to me that the folks on the SIPP list are NOT open to discussion. If there is discussion of BigTen, it will occur on some OTHER mailing list. You are, of course, welcome to join us. The basic plan is good its the way the address is structured. Also its a bit heavy on the concerns of the providers and router vendors and none on the other members of the networking paradigm. Its needs some weight in these other areas to balance it out. I think you miss the fact that it has, as it's sole concern, providing a reasonable service to the user community. Tony From Greg_Minshall@Novell.COM Fri Jun 3 17:53:00 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA12924 for ; Fri, 3 Jun 1994 20:56:22 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA29908; Fri, 3 Jun 94 18:55:27 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB21567; Fri, 3 Jun 94 17:53:00 PDT Date: Fri, 3 Jun 94 17:53:00 PDT Message-Id: <9406040053.AB21567@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Brian.Carpenter@cern.ch From: Greg Minshall Subject: Re: re An Architecture for BigTen Address Allocation Cc: ipng@cmf.nrl.navy.mil Brian, >Nothing must happen to my internal addressing scheme when I change service >provider, or if my corporate network is multi-homed on several service >providers. As far as I can see this imposes a constraint that it must be >possible to distinguish the prefix from the rest of the address by >inspection. Do you mean that you can't go around changing all your hosts "every time" you change providers? Do you mean that you can't go around changing all your "leaf routers" every time you change providers? Do you mean that you can't go around changing all your backbone routers every time you change providers? Do you mean you can't go around changing all your border routers every time you change providers? Greg From mankin@radegond.cmf.nrl.navy.mil Sat Jun 4 03:17:05 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id DAA13919 for ; Sat, 4 Jun 1994 03:17:09 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id DAA05112; Sat, 4 Jun 1994 03:17:06 -0400 Message-Id: <199406040717.DAA05112@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: Craig Partridge Subject: Re: IMPORTANT: IPng Retreat Cc: ipng@radegond.cmf.nrl.navy.mil In-reply-to: Your message of "Thu, 02 Jun 94 11:12:20 PDT." <199406021812.LAA21952@aland.bbn.com> Date: Sat, 04 Jun 94 03:17:05 -0400 From: Allison J Mankin > By the way, odd ball question -- I have notes I made about some of the > White Papers (preliminary reviews). Is there still use for this kind of > review or have the White Papers become OBE? Craig, The White Papers aren't OBE. We would be happy to have your reviews or notes posted to IPng. Scott and I hope they are winging their way to RFC and we will be citing at least some of them in our recommendation draft. We still want more of them, in fact, particularly from people in the gigabit and supercomputing community and from people in industries with big potential stakes in the Internet. Thank you. Allison / mankin@cmf.nrl.navy.mil From brian@dxcoms.cern.ch Sat Jun 4 16:12:42 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA14742; Sat, 4 Jun 1994 10:13:20 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10750; Sat, 4 Jun 1994 16:12:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27650; Sat, 4 Jun 1994 16:12:42 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406041412.AA27650@dxcoms.cern.ch> Subject: Re: 2nd IPNG Workshop--Outcome To: mankin@cmf.nrl.navy.mil (Allison J Mankin) Date: Sat, 4 Jun 1994 16:12:42 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <199406040026.UAA04422@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Jun 3, 94 08:26:03 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 401 I'll be in Boston, arriving either Friday or Saturday depending on the travel agent. I have to fly back Monday night so I may miss the end. Could somebody suggest a hotel? My expenses will be paid by RARE rather than by CERN for this trip. (RARE is the Association of European Research Networks.) Allison, I haven't moved house for 14 years. I can't imagine how bad it is for you. Courage! Brian From brian@dxcoms.cern.ch Sat Jun 4 16:48:54 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA14830 for ; Sat, 4 Jun 1994 10:49:28 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13785; Sat, 4 Jun 1994 16:48:55 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28273; Sat, 4 Jun 1994 16:48:54 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406041448.AA28273@dxcoms.cern.ch> Subject: Re: re An Architecture for BigTen Address Allocation To: Greg_Minshall@novell.com (Greg Minshall) Date: Sat, 4 Jun 1994 16:48:54 +0200 (MET DST) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil In-Reply-To: <9406040053.AB21567@WC.Novell.COM> from "Greg Minshall" at Jun 3, 94 05:53:00 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1707 Greg, I can change my routers of course. I cannot change my hosts, unless the change is 100% automatic. There are thousands of them, outside any kind of central control. So I conclude that if the prefix changes, this change must be automatically propagated to all the hosts. However if the prefix change forced a change in the suffix that is specific to each host, it could not be implemented on my site since we do not want full autoconfig for operational policy reasons. I think this also answers one of Tony Li's questions. Changing the prefix is OK, if it is propagated automatically and does not change the numbering plan for hosts. Same for changing the address length. That actually raises an interesting issue about autoconfig. Autoconfig of the prefix is necessary, since it may change. Autoconfig of the suffix must be available, but may not be wanted on a specific site. Brian >--------- Text sent by Greg Minshall follows: > > Brian, > > >Nothing must happen to my internal addressing scheme when I change service > >provider, or if my corporate network is multi-homed on several service > >providers. As far as I can see this imposes a constraint that it must be > >possible to distinguish the prefix from the rest of the address by > >inspection. > > Do you mean that you can't go around changing all your hosts "every time" > you change providers? Do you mean that you can't go around changing all > your "leaf routers" every time you change providers? Do you mean that you > can't go around changing all your backbone routers every time you change > providers? Do you mean you can't go around changing all your border > routers every time you change providers? > > Greg > > From jcurran@nic.near.net Sat Jun 4 11:10:44 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA15363 for ; Sat, 4 Jun 1994 14:28:01 -0400 Received: from [198.114.157.4] by nic.near.net id aa01476; 4 Jun 94 11:11 EDT To: Brian.Carpenter@cern.ch cc: Greg Minshall , ipng@cmf.nrl.navy.mil Subject: Re: re An Architecture for BigTen Address Allocation In-reply-to: Your message of Sat, 04 Jun 1994 16:48:54 +0200. <9406041448.AA28273@dxcoms.cern.ch> Date: Sat, 04 Jun 1994 11:10:44 -0400 From: John Curran Message-ID: <9406041111.aa01476@nic.near.net> -------- ] From: Brian Carpenter CERN-CN ] Subject: Re: re An Architecture for BigTen Address Allocation ] Date: Sat, 4 Jun 1994 16:48:54 +0200 (MET DST) ] ] Greg, ] ] I can change my routers of course. I cannot change my hosts, unless the ] change is 100% automatic. There are thousands of them, outside any kind ] of central control. So I conclude that if the prefix changes, this ] change must be automatically propagated to all the hosts. However if ] the prefix change forced a change in the suffix that is specific to ] each host, it could not be implemented on my site since we do not want ] full autoconfig for operational policy reasons. One day when you have some free time, could write a paragraph or two about your "operational policy reasons"? I'd like to understand what policies we need to worry about since other parts of IPng could also impact this. ] I think this also answers one of Tony Li's questions. Changing the prefix ] is OK, if it is propagated automatically and does not change the numbering ] plan for hosts. Same for changing the address length. Agreed. /John From bound@zk3.dec.com Sun Jun 5 09:25:49 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA17595 for ; Sun, 5 Jun 1994 09:30:57 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA26220; Sun, 5 Jun 94 06:25:57 -0700 Received: by xirtlu.zk3.dec.com; id AA28090; Sun, 5 Jun 1994 09:25:55 -0400 Message-Id: <9406051325.AA28090@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com, peter@goshawk.lanl.gov Cc: tli@cisco.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, tracym@3com.com Subject: Your Paper Source Route and Relative Addressing Date: Sun, 05 Jun 94 09:25:49 -0400 X-Mts: smtp Hi Yakov and Peter, Actual name of paper I am referencing is: Source Routing with Relative Addressing compared to Conventional Hierarchical Addressing and Source Routing I re-read your paper again late this week and used it with a couple of colleagues to sort out a similar discussion we are having regarding this whole issue of IPng address space. Its an excellent clear concise document covering the topic. I wish more documents and mail (mine too) could provide as much technical information and positioning as this document. I believe this should become an Informational RFC for the the entire IETF community. One enhancement strictly to add value is to add what is already in the document as one of the discussed 'effectors' to the abstractions discussed. It clearly discusses the 'space' trade-offs and indirectly discusses the 'time' trade-offs. Might be nice to see a paragraph discussing time/space complexity, which is inherent in the the document anyway. Another good use of this document will assist to support what a great man once stated as an objective for debate as an initial strategy which is: "Let us talk about where and what we agree about and then see if where we do not agree is less of an issue or at least more focused". p.s. I copied Bob, Tracy, and Tony as fyi. Sincerely, /jim From bound@zk3.dec.com Sun Jun 5 11:16:18 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17825 for ; Sun, 5 Jun 1994 11:20:31 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA01106; Sun, 5 Jun 94 08:16:26 -0700 Received: by xirtlu.zk3.dec.com; id AA02304; Sun, 5 Jun 1994 11:16:24 -0400 Message-Id: <9406051516.AA02304@xirtlu.zk3.dec.com> To: Tony Li Cc: yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: re An Architecture for BigTen Address Allocation In-Reply-To: Your message of "Fri, 03 Jun 94 15:24:41 PDT." <199406032224.PAA12432@lager.cisco.com> Date: Sun, 05 Jun 94 11:16:18 -0400 X-Mts: smtp Tony, First excellent response. Also it was hard for me to compose the response as I really wanted to stay away from any technical emotion or flaming too. Your response to my mail was very cool and will get me at least off on the right foot. Also nothing is cast in stone with me as an engineer. I will try to respond why I may not be able to be flexible on variable addresses and what they mean as a cost to a host. => 1. I do not want variable address formats that contain variable => addresses within those formats. This is just to complex and not required => to achieve the abstractions you request. The cost to hosts network => kernels is to great and we need a much simpler plan. I will just say now => 16bytes are enough for any address. >I will simply point out that anyone who claims that 16 bytes are >enough but 8 bytes weren't enough has a very difficult argument to >make. Given that of the second 8 bytes, 6 are given over to IEEE >addresses, you gain only two bytes of hierarcy, plus an additional >level if you decide to route on the IEEE address. So you're saying >that the additional 2 bytes make all of the difference in the world. >Forever. This could be a technical misunderstanding I would like to clear up and maybe we can move forward. I will try. If I have in the high order 8bytes (of a 16byte address) two fields that are 4bytes each that can aggregate to 4 billion addresses: Why can't they be used to support longest match on a router and support the CIDR style address use like in IPv4 at present. I realize this splits the hierarchical address in to two components and that creates a decision point. This gets to Yakov's and Peter's absolute vs relative address papers points and would need discussion I know. But if the high order 4 bytes represents all the providers in the world (this is why I do not believe right now questioned below that we need continental addresses denoted) then this should be enough address space to support providers distributed over the planet earth. The low order 4 bytes then contain for each provider an additional 4 billion addresses (which is probably overkill) for their subscribers. I won't go into at this point the sub-aggregates that can be defined in each of the 4 bytes above at this point. On the second 8 bytes. This gets to my new found belief in EIDs. I really believe that a portion of the address space should only define nodes, transport identifiers, and connections. I want to see this network abstraction separate from routing completely. This could be the one argument that could make me believe in lets say 24byte addresses. But right now I believe I can route with 8 bytes. This also gets to Brian Carpenters need to not have hosts affected by renumbering. If all you have to change is the routing (Locators) then the EIDs stay the same. The hosts do not have to change and there is only a Locator update to DNS for hosts and advertisement/solicitation system discovery convergence to absorb the routing address change for the private network. I believe this will work well with mobile too. But EIDs need to be done as an evolutionary process I am thinking after this weekend doing some prototyping. Hence, I now believe that we need to use subnet location within the EID and for Autoconfiguration. This reduces the complexity of converging to an EID type strategy for some part of the network address and will not upset greatly present algorithms and code base for IPv4 on a host. Maybe the scope of the EID stated above with this compromise may be more acceptable to the Directorate and the IETF community at large for IPng. I hope. The 2bytes for subneting are only local to a private site like BBN, XYZ, or CERN. Don't you believe 64K of address space is enough space for private subnets at a site? >I will just say now that 16 bytes are not enough for any address. As >you see from our addressing plan, 16 bytes ARE enough if you only need >3 or 4 levels of hierarchy. But it is pretty clear to some of us that >each level of hierarchy is necessarily sparsely populated so that you >can easily accomodate growth. The result is that for an internet of >more than tens of thousands of providers, with more than tens of >thousands of subscribers, you need more than 16 bytes. I guess this may be another good point of discussion and each topic could be discussed as one component in the abstraction which I believe as an exercise is very worthwhile. As I stated above I don't see why a properly defined address space cannot be aggregated to support what is being done with multiple levels of hierarchy. This might be something to add to your drafts as input for discussion. => 2. I don't like the idea at all of providers getting together and => defining my address hierarchy. If a private company does not want to be => a good citizen then they don't have to be thats free enterprise. Its => been a problem for software development since our business started so I => can't support this line of thinking philosophically or technically. >I think that there's some radical misunderstanding here. The >providers are responsible for providing you with a prefix. Your >private company is soley responsible for defining your address >hierarchy within that prefix. => "It is the joint responsibility of the region, the provider => and the subscriber to agree on their local addressing structure." OK. I just needed to hear you say it again I guess. Just watching the Anti-Trust issues here. I think we need to make sure any solution does not adversely affect anyones business or give to much leverage to any one entity in this future market at the cost of another entity. Or another outcome could be a walking-away from the IETF and a vendor consortium started for networking. This is a popular alternative to standards these days and I think could be devastating if attempted for the network layer of TCP/IP. It would usurp the entire market until it got sorted out. => 3. I don't see the value of registry identifiers in addresses? I think => the idea in RFC1466 is a good one, but I don't see the need to take up => space in the address for this function. >Registry identifiers are just another topologically sensitive level of >hierarchy. See the section on continental aggregation in the >addressing architecture for their use. Or do you disagree with the >need for continental aggregation? Yes I disagree with continental aggregation. I think these boundaries should be avoided for the topology and use aggregate addressing for the planet earth. I think this will still work with your multihome sections of the draft too, which is real important too as a side comment. In addition in the next part of my response I attempt to give you a short list of the pain of variable address structures and that then contain variable addresses. But that complexity increases f(n**z) where n is yet another format and z being the square of the iterative possibility of a format in a series computation. I won't go into that below, but continental aggregation with n formats is just too much and why I am very concerned about another IPng topic called convergence supporting other than IPng addresses within the IPng address solution. Its not that I want to exclude other protocols from IPng I am just not convinced we can solve that problem in a manner that contains acceptable costs. But if at the end of the day for IPng we need to keep these kind of data items for routing then I would like to see them put in the network header not in the address. Let the address exist by itself as a complete abstraction which has only contructor, selector, and iterative operations performed on it as a network entity. This also means we can probably make the address itself align on a 32 bit or 64bit boundary, which for a host is very critical and a big performance win. => The bottom line is the variable address strategy will not work for a => host. If the objectives can be achieved with fixed addresses in this => document then this would be wonderful. >The bottom line is that the variable length address strategy CAN work >for hosts who are willing to code primitives to manipulate addresses. >[Personally, I find that gcc provides exactly the correct facility >with inline functions.] The hosts CAN easily incorporate >optimizations for the profiled address lengths within the address >manipulation routines. The sole question is whether or not host >vendors are willing to invest now in implementing an architecture >which will not need replacement within the forseeable future. So far, >the answer has been no. Its not easy believe me. Yes it can be done. I know it can be done but at what cost. I have probably written at least 1/2 million lines of code in the last 20 years and I know anything can be done. But, at what cost. In the case of a host networking kernel here are a few of the changes that would be required: 1. New algorithms for all cache management at the transport, network, and datalink abstraction layers. 2. Protocol control blocks, connection state queues, and address kernel representation structure (sockets) abstractions would have to be altered to support length indication and then memory allocation/deallocation. 3. Searches on the above would need to redesigned to provide similar performance (and greater if possible) as IPv4 today. 4. Virtual memory interface for the networking subsystem of the host operating system would need to be more dynamic to support variable structures and then the garbage collection of those structures once void as state. For implementations that do not use linked lists but arrays this is very complex to figure out. 5. Wherever the actual address (not non address parts or length indicators) do not align on machine architecture boundaries additional instructions will be required to create alignment for loading and masking. 6. Variable addresses also will affect inline code to DNS interaction and all the future abstractions for this very critical piece to the distributed networking paradigm. This affects applications too. I know some believe APIs can treat the network layer address as opaque, but this is simply not possible without much agreement and standards on generic data structures that will also perform at the interface between the transport layer and the application layer. I will stop with these points for now. Are you suggesting by the gcc inline code function (I am not a fan or user of gcc but...) that host use compilers to absorb the alterations of variable addresses? Doing this would also have a great cost and I think if variable addresses were accepted not to many host vendors would go this route because the ramifications could be more costly than re-structuring their network OS kernel subsystems. At least for the first several years of IPng deployment. I always like to tell business or marketing folks that ask me to do the exceptional with softare : "heck I could write code for you that executes on the right machine that will shine your shoes and tie them for you if you want to pay for it and think we can make the kind of revenue our enterprise requires". I would like to make a comparison to altering the host to support this draft to tHe changes to support NIMROD. We are now not talking an incremental network update to host networking software but a major overhaul and redesign. From my perspective if we are going to do this then we may as well redesign IPv4 completely and probably parts of the transport layer abstraction. => I cannot support this draft in its current form its unacceptable to host => implementations. I know this will take a lot of discussion and I will => point you to the SIPP list where this has been discussed at length. I => suggest you send this draft to the SIPP list and see what response you => get as there is a lot of host talent on that list. This may be a good => place to iron out the issues. >I have two basic objections to this: first, I'm waiting for Yakov, as >he's off the net for a moment and am loathe to embroil him in a flame >fest without his approval. Second, I fail to see what can be gained >by doing this. It's very clear from your own response that this is >very much a religious issue. It's pretty clear to me that the folks >on the SIPP list are NOT open to discussion. If there is discussion >of BigTen, it will occur on some OTHER mailing list. You are, of >course, welcome to join us. I hope that my response above makes this clear its not a religious response, but a genuine discussion of concern on the amount of investment a host system needs to make to support IPng. Regarding SIPP this is not the case. I think the problem is that it does not seem to get to this level of detail, but I find that to be true on many IETF lists. We have lots of experts in different areas and sometimes we have two people with different expertises, but generally the same level of knowledge about networking with different focuses debating a technical point. What would be good is if folks took tHe time to determine where more definition and explanation of their focus would be useful to the discussion to obtain a better debate of the technical point. I believe if we did this then we could move forward in a steady pace. It may seem like it would be slower to have to go to that level of detail, but I have found that in the long run its faster. How long have we been working on IPng and how many of these discussions keep getting re-hashed. This happens on many lists for many subjects. The real problem is folks are afraid or uncomfortable with saying 'I don't know'. This is not good. I ask you and many off line to explain to me what this means or why do that etc in the routing space. Now I am seeing many of these issues and focusing on that part of IPng for our prototype a lot. But its also true that to say for example via sockets API just build and opaque address (said by many in and out of the IETF) when they may not have all the knowledge of what makes up an API and the interfaces at the network layer and the representative structures at the datalink dependent layer with casual commentary is not good either. => The basic plan is good its the way the address is structured. Also its => a bit heavy on the concerns of the providers and router vendors and none => on the other members of the networking paradigm. Its needs some weight => in these other areas to balance it out. >I think you miss the fact that it has, as it's sole concern, providing >a reasonable service to the user community. I have had this debate internally in two companies. The user community in this case is the market and the IETF. This includes host vendors who have to build products, which affect ISVs (as an example) who have to build applications. Its all integrated and changing one affects the effort to come to market, maintain a product, or create extensibility in the design. The debate in the two companies is can one justify an investment that will save engineering costs, but will provide no new tangible benefits to a paying customer using that product line. So its not that I miss the fact, but rather I am taking a very broad view of the user community. Someone told me once when I was playing baseball for a league to not view the game from my position at 3rd base, but view it from the perspective of all tHe posiitons maybe by watching more baseball games in the grandstand and get off the infield once in awhile. But as I said in my original response I think the provider user community is critical to the success of IPng and this draft clearly articulates that point. I am not against variable addresses from a computer science perspective. But am concerned as an engineer who will have to deliver a product thAt tHe costs based on what I think the IPng enhanced function should provide for the TCP/IP suite is reasonable and can be delivered within an acceptable time-to-market window on a host. /jim From pvm@ISI.EDU Sun Jun 5 17:00:03 1994 Return-Path: pvm@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18942 for ; Sun, 5 Jun 1994 20:05:37 -0400 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Sun, 5 Jun 1994 17:02:51 -0700 Message-Id: <199406060002.AA14010@zephyr.isi.edu> To: Allison J Mankin Cc: ipng@radegond.cmf.nrl.navy.mil, iesg@cnri.reston.va.us Reply-To: pvm@ISI.EDU Subject: Re: schedule for Toronto In-Reply-To: Your message of Wed, 01 Jun 1994 04:16:58 -0400. <199406010816.EAA14719@radegond.cmf.nrl.navy.mil> Date: Sun, 05 Jun 94 17:00:03 PDT From: Paul Mockapetris I have asked Steve Coya to pencil in the morning of friday for a putative IESG meeting. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From francis@cactus.slab.ntt.jp Mon Jun 6 09:05:11 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id UAA18941; Sun, 5 Jun 1994 20:05:37 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 6 Jun 1994 09:05:12 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id JAA00776; Mon, 6 Jun 1994 09:03:53 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA20415; Mon, 6 Jun 94 09:05:11 JST Date: Mon, 6 Jun 94 09:05:11 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406060005.AA20415@cactus.slab.ntt.jp> To: craig@aland.bbn.com, mankin@cmf.nrl.navy.mil Subject: Re: IMPORTANT: IPng Retreat Cc: ipng@radegond.cmf.nrl.navy.mil This is my rsvp.... I won't be able to go to this retreat..... PF From tli@cisco.com Mon Jun 6 01:23:32 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id EAA20128 for ; Mon, 6 Jun 1994 04:28:00 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA12319; Mon, 6 Jun 1994 01:23:32 -0700 Date: Mon, 6 Jun 1994 01:23:32 -0700 From: Tony Li Message-Id: <199406060823.BAA12319@lager.cisco.com> To: bound@zk3.dec.com Cc: yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Sun, 05 Jun 94 11:16:18 -0400 <9406051516.AA02304@xirtlu.zk3.dec.com> Subject: re An Architecture for BigTen Address Allocation Jim, This could be a technical misunderstanding I would like to clear up and maybe we can move forward. I will try. If I have in the high order 8bytes (of a 16byte address) two fields that are 4bytes each that can aggregate to 4 billion addresses: Why can't they be used to support longest match on a router and support the CIDR style address use like in IPv4 at present. A 4 byte field is not practical in constructing the hierarchy. It implies that there is no topological information contained within those 4 bytes. Thus, all routers within that area could conceivably have to carry up to 2^32 routes (a _challenging_ task) and worse yet, search through a routing table of this size when switching. Note that this is a technology-independent analysis. Searching the routing table will always become slower as you add possibilities. Making time space tradeoffs will be possible, but what you're suggesting requires more growth than we can readily forsee. For example, today's routers have 64Mbytes of memory (26 bits). If we follow Moore's law, we can add one bit every two years. That's 12 years before 32 bits of addressible memory. Oh, and we probably need to store more than one byte per route. Say (for simplicity) that we need 256 bytes per route (one byte -- probably needs to be a lot more, it is right now). That's another 16 years. Or a total of 28 years before we can deploy routers, and even then, they're extremely expensive. Radical thinkers, such as Dr. Deering, suggest that we could have an addressing plan with 20-bit flat levels (1 million routes) within the near time frame. Being more conservative and wanting to deploy something within a shorter time frame, we've used only 16-bit flat levels (64k routes) for the BigTen addressing plan. If this is starting to hurt your neurons (it does to mine ;-), here's the basic synopsis: - We want to have a very big net. - It requires hierarchy with multiple levels. - Each level must be sparsely populated to allow for growth. - We can't build arbitrarily wide levels as we can only support some constant amount of fanout at any level of the hierarcy. - Thus, adding hierarchy wastes addresses (due to sparseness) but buys scalability. If you sense an engineering tradeoff here with diminishing returns at either extreme, you're on the right track. I won't go into at this point the sub-aggregates that can be defined in each of the 4 bytes above at this point. This is key and you shouldn't dismiss it. It's _exactly_ what we've done with BigTen. The low order 4 bytes then contain for each provider an additional 4 billion addresses (which is probably overkill) for their subscribers. That's not clear, and you shouldn't dismiss that so quickly either. Again, the provider needs to provider hierarchy within his network and the subscriber needs to provide hierarchy within their network. These are also going to be very lossy additional layers. I know organizations that have literally asked for (and needed) multiple class A's. There's 4 bytes right there. The provider needs at least two, and probably three. On the second 8 bytes. This gets to my new found belief in EIDs. I really believe that a portion of the address space should only define nodes, transport identifiers, and connections. I want to see this network abstraction separate from routing completely. This could be the one argument that could make me believe in lets say 24byte addresses. But right now I believe I can route with 8 bytes. Let me ask you this: Why should the EID, which MUST NOT contain location information, exist as a subset of the locator? You've just said that the EID should be separate from routing completely. Why are the EID's in the object that we route on? The 2bytes for subneting are only local to a private site like BBN, XYZ, or CERN. Don't you believe 64K of address space is enough space for private subnets at a site? No, not a chance. cisco itself has multiple class B's. And we're TINY compared to some of our customer networks. >But it is pretty clear to some of us that >each level of hierarchy is necessarily sparsely populated so that you >can easily accomodate growth. The result is that for an internet of >more than tens of thousands of providers, with more than tens of >thousands of subscribers, you need more than 16 bytes. I guess this may be another good point of discussion and each topic could be discussed as one component in the abstraction which I believe as an exercise is very worthwhile. As I stated above I don't see why a properly defined address space cannot be aggregated to support what is being done with multiple levels of hierarchy. This might be something to add to your drafts as input for discussion. Sorry, I can't parse this. >Registry identifiers are just another topologically sensitive level of >hierarchy. See the section on continental aggregation in the >addressing architecture for their use. Or do you disagree with the >need for continental aggregation? Yes I disagree with continental aggregation. I think these boundaries should be avoided for the topology and use aggregate addressing for the planet earth. I think this will still work with your multihome sections of the draft too, which is real important too as a side comment. I'm having a tough time here too. I trust I've made my comments about the size of flat fields above with sufficient clarity. In addition in the next part of my response I attempt to give you a short list of the pain of variable address structures and that then contain variable addresses. But that complexity increases f(n**z) where n is yet another format and z being the square of the iterative possibility of a format in a series computation. I won't go into that below, but continental aggregation with n formats is just too much and why I am very concerned about another IPng topic called convergence supporting other than IPng addresses within the IPng address solution. Its not that I want to exclude other protocols from IPng I am just not convinced we can solve that problem in a manner that contains acceptable costs. I'm now incredibly confused. Continental aggregation is not something that is conceptually any different than aggregation at any other level. Certainly no software should ever, EVER, *EVER* know about the current hierarchical address assignment structure. Host should simply see a prefix to which they append their 802 address. Routers would simply see other prefixes of varying lengths floating around and may be instructed to perform aggregation. Put another way: we learned from classfullness and we'll not be making the same mistake again. Software will know that an address is of a certain length and is an opaque bit string. Period. >The sole question is whether or not host >vendors are willing to invest now in implementing an architecture >which will not need replacement within the forseeable future. So far, >the answer has been no. Its not easy believe me. Yes it can be done. I know it can be done but at what cost. I have probably written at least 1/2 million lines of code in the last 20 years and I know anything can be done. But, at what cost. In the case of a host networking kernel here are a few of the changes that would be required: 1. New algorithms for all cache management at the transport, network, and datalink abstraction layers. 2. Protocol control blocks, connection state queues, and address kernel representation structure (sockets) abstractions would have to be altered to support length indication and then memory allocation/deallocation. 3. Searches on the above would need to redesigned to provide similar performance (and greater if possible) as IPv4 today. 4. Virtual memory interface for the networking subsystem of the host operating system would need to be more dynamic to support variable structures and then the garbage collection of those structures once void as state. For implementations that do not use linked lists but arrays this is very complex to figure out. 5. Wherever the actual address (not non address parts or length indicators) do not align on machine architecture boundaries additional instructions will be required to create alignment for loading and masking. 6. Variable addresses also will affect inline code to DNS interaction and all the future abstractions for this very critical piece to the distributed networking paradigm. This affects applications too. I know some believe APIs can treat the network layer address as opaque, but this is simply not possible without much agreement and standards on generic data structures that will also perform at the interface between the transport layer and the application layer. I will stop with these points for now. I'll make one point: we aren't designing IPng for today's hardware. Nor today's software. [Ok, I can't resist: point 5 is a no-op. We're already correctly aligned, thank you. Because it helps the host vendors.] Are you suggesting by the gcc inline code function (I am not a fan or user of gcc but...) that host use compilers to absorb the alterations of variable addresses? No, I'm saying that the implementation costs are greatly reduced if you can abstract your code from base address manipulations. Doing this would also have a great cost What? You're already going through your kernel converting 32 bit ints to 64 bit addresses. Change them to an opaque type. Convert address copy operations (today a simple assignment) to a function call. You've got to touch the code already. It's simply time to do The Right Thing. I think if variable addresses were accepted not to many host vendors would go this route because the ramifications could be more costly than re-structuring their network OS kernel subsystems. At least for the first several years of IPng deployment. I find this hard to believe. You're arguing that they would be willing to go to a fixed length different address, but not a variable length one? Given that the techniques for dealing with variable length addresses are already quite well understood (thank you again, Berkeley), I think you need to defend this statement. As a router vendors we also manipulate addresses. Lots of 'em. Frequently. Yes, we see that there is an _incremental_ additional cost to variable length addresses. However, that cost is quite small and is very much up front in training the programmers to live with a new paradigm. Mortgaging the future of the Internet or spending two weeks of programmer time is a relatively straightforward choice for us. What is so very different for the host vendor community? I always like to tell business or marketing folks that ask me to do the exceptional with softare : "heck I could write code for you that executes on the right machine that will shine your shoes and tie them for you if you want to pay for it and think we can make the kind of revenue our enterprise requires". Well Jim, our grandkids want us to pay for it, and we've already proven that it makes megabucks. ;-) I would like to make a comparison to altering the host to support this draft to tHe changes to support NIMROD. We are now not talking an incremental network update to host networking software but a major overhaul and redesign. From my perspective if we are going to do this then we may as well redesign IPv4 completely and probably parts of the transport layer abstraction. Funny, that's what I thought we were doing. No ;-). I believe the charter is to create a new network layer, no holds barred. I saw nothing that said that we had to retain IPv4 as a base for IPng. Just transition away from IPv4. This cannot be an incremental network update. The cost is way too high. It's already not incremental by the time we get to SIPP. It _is_ a new architecture, supporting new features such as flows, multicasting and source routing as first-class citizens for the first time. I have had this debate internally in two companies. The user community in this case is the market and the IETF. Nope, sorry. This is confused. The user community here is just the users. The market and the IETF are the producers of IPng. The debate in the two companies is can one justify an investment that will save engineering costs, but will provide no new tangible benefits to a paying customer using that product line. ? I fail to see how this is even a debate. Saving engineering costs implies that overhead goes down. Less cost, same result means more profit. Mr. Morgridge would be happy to expound on this for you. ;-) So its not that I miss the fact, but rather I am taking a very broad view of the user community. Someone told me once when I was playing baseball for a league to not view the game from my position at 3rd base, but view it from the perspective of all tHe posiitons maybe by watching more baseball games in the grandstand and get off the infield once in awhile. Good advice. How about viewing it from the grandstand and getting off of the host vendor position for a bit? I am not against variable addresses from a computer science perspective. But am concerned as an engineer who will have to deliver a product thAt tHe costs based on what I think the IPng enhanced function should provide for the TCP/IP suite is reasonable and can be delivered within an acceptable time-to-market window on a host. A fine concern. Let's take your suggestion and be more detailed. In your enumerated list of points above, it's clear that the cost is non-zero. But it is not overwhelming either. [You didn't say that you COULDN'T POSSIBLY implement it.] Can you quantify the costs in terms of nerd-clue-years? For cisco, I'd say that the difference is about 1 nerd-clue-year, amortized over the whole engineering department. What are the benefits? Well, this is the tough one. I've been comparing it to buying earthquake insurance in California. If you get hit by the Big One, you Really need it. If you don't get hit, then it's a clear waste. It's a risk that needs to be managed. The cost in the case that 16 bytes are not enough are basically infinite. We have IPng++. We do this whole thing again, and in the BEST case, it's our grandkids doing it. What is the probability that we'll run out of 16 byte addresses? Well, this is pretty subjective. But I think that everyone will agree that they are non-zero. We certainly know that when IPv4 was designed and when the telephone numbering system was designed, that they argued that there was "enough" address space. They were both wrong. I think it is an act of utter hubris to think that we'll do any better. For the sake of discussion, let's say that the probability is 10% (I personally think it's more like 90%). Are you willing to live with the fact that the infrastructure we architect today has a 10% chance of complete failure? In no other engineering realm would this be acceptable. Think about this the next time you drive across a bridge. Tony p.s. I'm sorta on vacation right now, so my replies may tend to lag a bit. From jallard@microsoft.com Mon Jun 6 17:20:31 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA25901 for ; Mon, 6 Jun 1994 20:25:48 -0400 From: jallard@microsoft.com Received: by netmail2.microsoft.com (5.65/25-eef) id AA19410; Mon, 6 Jun 94 16:27:26 -0700 Message-Id: <9406062327.AA19410@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 06 Jun 94 16:27:26 PDT X-Msmail-Message-Id: E26AE708 X-Msmail-Conversation-Id: E26AE708 To: ipng-request@cmf.nrl.navy.mil Date: Mon, 6 Jun 94 17:20:31 TZ Subject: RE: IPNG Retreat part deux i'm trying to get there, i'll let you know later this week. ---------- | From: Steve Coya | To: | Subject: IPNG Retreat part deux | Date: Monday, June 06, 1994 6:33PM | | Received: from picard.cmf.nrl.navy.mil by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA17544; Mon, 6 Jun 94 15:40:28 -0700 | Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us | [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) | with SMTP id SAA25389 for ; Mon, 6 Jun | 1994 18:34:51 -0400 | Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10470; | 6 Jun 94 18:33 EDT | Message-Id: <9406061833.aa10470@IETF.CNRI.Reston.VA.US> | | Greetings, | | Am trying to prepare a list of who will be participating iin the | retreat... along with the location per person. Here is what I have so | far... please let me know your plans and I will consolodate for the | entire directorate. | | | Steve | ============================================================ | | Scott Bradner Yes Boston | Allison Mankin Yes Boston | | J Allard, Mircosoft ??? | Steve Bellovin, AT&T No | Jim Bound, DEC Yes Boston | Ross Callon, Wellfleet Yes Boston | Brian Carpenter, CERN Yes Boston | Dave Clark, MIT Yes Boston | Jon Crowcroft, UCL ??? | John Curran, NEARnet Yes Boston | Steve Deering, Xerox PARC Yes Bay Area | Dino Farinacci, Cisco Yes Bay Area | Eric Fleischman, Boeing No | Paul Francis, NTT No | Frank Kastenholz, FTP ??? | Mark Knopper, Ameritech ??? | Greg Minshall, Novell Yes Boston | Craig Partridge, BBN ??? | Rob Ullmann, Lotus ??? | Lixia Zhang, Xerox PARC Yes Boston | | From bound@zk3.dec.com Mon Jun 6 10:32:44 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA21722 for ; Mon, 6 Jun 1994 10:38:38 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA20329; Mon, 6 Jun 94 07:33:05 -0700 Received: by xirtlu.zk3.dec.com; id AA13411; Mon, 6 Jun 1994 10:32:50 -0400 Message-Id: <9406061432.AA13411@xirtlu.zk3.dec.com> To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil Subject: Re: re An Architecture for BigTen Address Allocation In-Reply-To: Your message of "Mon, 06 Jun 94 01:23:32 PDT." <199406060823.BAA12319@lager.cisco.com> Date: Mon, 06 Jun 94 10:32:44 -0400 X-Mts: smtp Tony, => If I have in the high order 8bytes (of a 16byte address) two fields that => are 4bytes each that can aggregate to 4 billion addresses: => Why can't they be used to support longest match on a router => and support the CIDR style address use like in IPv4 at present. =>A 4 byte field is not practical in constructing the hierarchy. It implies =>that there is no topological information contained within those 4 bytes. =>Thus, all routers within that area could conceivably have to carry up to =>2^32 routes (a _challenging_ task) and worse yet, search through a routing =>table of this size when switching. Note that this is a =>technology-independent analysis. Searching the routing table will always =>become slower as you add possibilities. >Making time space tradeoffs will be possible, but what you're suggesting >requires more growth than we can readily forsee. For example, today's >routers have 64Mbytes of memory (26 bits). If we follow Moore's law, we >can add one bit every two years. That's 12 years before 32 bits of >addressible memory. Oh, and we probably need to store more than one byte >per route. Say (for simplicity) that we need 256 bytes per route (one byte >-- probably needs to be a lot more, it is right now). That's another 16 >years. Or a total of 28 years before we can deploy routers, and even then, >they're extremely expensive. OK. Needed to hear this. Thanks... We do need to be practical so we can deploy. >Radical thinkers, such as Dr. Deering, suggest that we could have an >addressing plan with 20-bit flat levels (1 million routes) within the near >time frame. Being more conservative and wanting to deploy something within >a shorter time frame, we've used only 16-bit flat levels (64k routes) for >the BigTen addressing plan. Whats the maximum routes at any one router point Cisco has seen today (maybe from ALE work we know this too)? Its seems big enough if no individual router has to know of all routes for the IPng Internet which I will assume is the case? >If this is starting to hurt your neurons (it does to mine ;-), here's the >basic synopsis: >- We want to have a very big net. >- It requires hierarchy with multiple levels. >- Each level must be sparsely populated to allow for growth. >- We can't build arbitrarily wide levels as we can only support some > constant amount of fanout at any level of the hierarcy. >- Thus, adding hierarchy wastes addresses (due to sparseness) but buys > scalability. >If you sense an engineering tradeoff here with diminishing returns at >either extreme, you're on the right track. Yes I do. => On the second 8 bytes. This gets to my new found belief in EIDs. I => really believe that a portion of the address space should only define => nodes, transport identifiers, and connections. I want to see this => network abstraction separate from routing completely. This could be the => one argument that could make me believe in lets say 24byte addresses. => But right now I believe I can route with 8 bytes. >Let me ask you this: Why should the EID, which MUST NOT contain location >information, exist as a subset of the locator? You've just said that the >EID should be separate from routing completely. Why are the EID's in the >object that we route on? I would prefer they not be but I am losing this battle so I guess I am whimpering and giving up. I see the compromise that 8 bytes of the IPng address can at least treated as an EID at the transport. If this is possible I would suggest that transport connections and applications not carry 16 or 24 bytes but only the 8 bytes from the IPng address. I have not asked this yet, but I just let the cat out of the bag here in this message. I really think carrying anymore than 8 bytes for a transport address is bad. I don't mind carrying the complete IPng address in DNS and passing it down to the transport and then network layer, I just don't want to use it at the transport. I don't think an EID needs to be in any routable packets address off the LAN, but it does need to be somewhere in the packet so it can be delivered to the end node once the final subnet destination is reached. => The 2bytes for subneting are only local to a private site like BBN, => XYZ, or CERN. Don't you believe 64K of address space is enough space => for private subnets at a site? >No, not a chance. cisco itself has multiple class B's. And we're TINY >compared to some of our customer networks. Need some clarity here. If you aggregate 16bits thats 64K subnets. Cisco has more than 64K subnets? = >But it is pretty clear to some of us that = >each level of hierarchy is necessarily sparsely populated so that you = >can easily accomodate growth. The result is that for an internet of = >more than tens of thousands of providers, with more than tens of = >thousands of subscribers, you need more than 16 bytes. ==> I guess this may be another good point of discussion and each topic ==> could be discussed as one component in the abstraction which I believe ==> as an exercise is very worthwhile. As I stated above I don't see why a ==> properly defined address space cannot be aggregated to support what is ==> being done with multiple levels of hierarchy. This might be something ==> to add to your drafts as input for discussion. >Sorry, I can't parse this. You have answered this question above. I was asking why can't we just aggregate 32bits to support 4 billion addresses, instead of abstracting the hierarchy as in the draft. Now I would ask that the limitations of routers present memory (20 bits) be added to the draft so we understand why what I suggest is not feasible today. Also the search on a potential 32bit aggregate could be quite consuming as you pointed out. We are still dealing with hardware limitations. If I can find the time I will try to see how fast I can do a 32bit aggregate search on an Alpha just for grins. = >Registry identifiers are just another topologically sensitive level of = >hierarchy. See the section on continental aggregation in the = >addressing architecture for their use. Or do you disagree with the = >need for continental aggregation? ==>Yes I disagree with continental aggregation. I think these boundaries ==>should be avoided for the topology and use aggregate addressing for the ==>planet earth. I think this will still work with your multihome sections ==>of the draft too, which is real important too as a side comment. >I'm having a tough time here too. I trust I've made my comments about the >size of flat fields above with sufficient clarity. Yes. => In addition in the next part of my response I attempt to give you a => short list of the pain of variable address structures and that then => contain variable addresses. But that complexity increases f(n**z) where => n is yet another format and z being the square of the iterative => possibility of a format in a series computation. I won't go into that => below, but continental aggregation with n formats is just too much and => why I am very concerned about another IPng topic called convergence => supporting other than IPng addresses within the IPng address solution. => Its not that I want to exclude other protocols from IPng I am just not => convinced we can solve that problem in a manner that contains acceptable => costs. >I'm now incredibly confused. Continental aggregation is not something that >is conceptually any different than aggregation at any other level. >Certainly no software should ever, EVER, *EVER* know about the current >hierarchical address assignment structure. Host should simply see a prefix >to which they append their 802 address. Routers would simply see other >prefixes of varying lengths floating around and may be instructed to >perform aggregation. >Put another way: we learned from classfullness and we'll not be making the >same mistake again. Software will know that an address is of a certain >length and is an opaque bit string. Period. Two concerns in my above response. One was the 32bit aggregate again. You have answered that question. The second part was the issue of supporting multiple address formats. Today with IPv4 I have multiple class addresses. When I receive them thats OK if an A talks to a B as you said I don't care. But all is well because each of them are 4bytes. It makes the software neat and clean and balanced and everything is aligned. What I am concerned about is having to parse address X as an incoming connection and my address type is Y with different length addresses. For example one is a 6byte 802 address and another is a 10byte xxx address. This gets to why EIDs are good. Make all node IDs for processing above the network layer say 8 bytes. I don't care about the routing state just the node ID when not dealing with a routing code path. It makes it much more simple. But EIDs must be globally unique. >I'll make one point: we aren't designing IPng for today's hardware. Nor >today's software. Well I am? This is a key issue I think for us to understand to reach consensus. If we need to be constrained for initial deployment because of a component of the network implementation such as a router or terminal server as examples then we need to absorb that into our technical solution for IPng. But what we also need to do is develop an IPng technical strategy that is extensible that can absorb enhancements in component architecture without doing IPng+. This PIP gave us IMHO, and NIMROD too. => Are you suggesting by the gcc inline code function (I am not a fan or => user of gcc but...) that host use compilers to absorb the alterations of => variable addresses? >No, I'm saying that the implementation costs are greatly reduced if you can >abstract your code from base address manipulations. => Doing this would also have a great cost >What? You're already going through your kernel converting 32 bit ints to >64 bit addresses. Change them to an opaque type. Convert address copy >operations (today a simple assignment) to a function call. You've got >to touch the code already. It's simply time to do The Right Thing. Doing this to just make the existing environment work would be a quick hack true for a prototype. But to build an OS network product we would have to spend much time restructuring to support my previous points regarding changes to the kernel. And that does have great costs. => I think => if variable addresses were accepted not to many host vendors would go => this route because the ramifications could be more costly than => re-structuring their network OS kernel subsystems. At least for the => first several years of IPng deployment. >I find this hard to believe. You're arguing that they would be willing to >go to a fixed length different address, but not a variable length one? >Given that the techniques for dealing with variable length addresses are >already quite well understood (thank you again, Berkeley), I think you need >to defend this statement. I can't speak for other host vendors but we have implemented 4.4 and can handle either 4.3 (no length field) or 4.4 (with length field), but no one is really using it for IPv4 to my knowledge. So we have not seen the ramifications at this time on caching, control blocks, queues, etc being based on variable addresses and the list in my previous response. Just because Berkeley added the sa_len field does not mean anyone is using it. It can be used in a SIPP prototype (see most recent SIPP API spec). But this is only a socket address and permits other protocols besides TCP/IP from the API build other than 32bit address architectures within a Berkeley kernel. What was not done is change all the structures or even add typedefs to the kernel to support a varible infrastructure for the network kernel. This would have to be done for IPng if incoming and outgoing connections became variable. The bottom line is no one is looking at the sa_len field extension to process IPv4 packets. The sa_len does permit us to set up an array of 4 or 8 byte addresses for IPng. Presently in SIPP we can treat the first 8 bytes as an identifying address the additional 8byte addresses for extended routing are available to the network layer if needed incoming or outgoing. >From a structure point of view all the connections are based on 8byte search abstractions. The issue is now adding a length to determine the search. This is avoided with fixed length addresses. I not only have to load a length value but design a way to key off of variable structures or strings unless I put all types in the same queue and use multiple queues depending on the big 10 locator type which is the way I think may be most efficient. But you don't just go in and change a Berkeley kernel this way without verifying what it does to the rest of the system. So what Berkeley did was provide the ability to evolve towards variable addresses not implement a kernel that has been changed to support variable address structures. >As a router vendors we also manipulate addresses. Lots of 'em. >Frequently. Yes, we see that there is an _incremental_ additional cost to >variable length addresses. However, that cost is quite small and is very >much up front in training the programmers to live with a new paradigm. >Mortgaging the future of the Internet or spending two weeks of programmer >time is a relatively straightforward choice for us. What is so very >different for the host vendor community? I think the difference is the scope of the operating system inter-dependencies. Its not just re-training the programmers to deal with variable addresses its altering the network subsystem to deal with variable addresses. We for example made a large investment similar to this when we went from a BSD kernel to an OSF/1 kernel (BSD extended), and then within a close proximity from a 32bit machine architecture to a 64bit machine architecture. It was more than two weeks of training and required a lot of design work. You don't know what your facing until you begin changing a kernel for networking. For example many folks used the fact that a pointer was 32bits and hence an IPv4 address can be a pointer type. Well when your pointer becomes 64bits it breaks. These are problems you don't think about until you begin to make the upgrade. Now I admit if all engineering was done properly much of the pain that might happen with variable addresses should not happen. But that unfortuneately is not reality. Ill behaved software exists everywhere. Often to gain performance. => I would like to make a comparison to altering the host to support this => draft to tHe changes to support NIMROD. We are now not talking an => incremental network update to host networking software but a major => overhaul and redesign. From my perspective if we are going to do this => then we may as well redesign IPv4 completely and probably parts of the => transport layer abstraction. >Funny, that's what I thought we were doing. No ;-). I believe the charter >is to create a new network layer, no holds barred. I saw nothing that said >that we had to retain IPv4 as a base for IPng. Just transition away from >IPv4. >This cannot be an incremental network update. The cost is way too high. >It's already not incremental by the time we get to SIPP. It _is_ a new >architecture, supporting new features such as flows, multicasting and >source routing as first-class citizens for the first time. Well variable addresses would be a new addition. In addition the changes required, which we are discussing, there is still the performance issue of checking length fields. It might be good to get some kind of hard analysis on this, and I am working on this now at my end. => So its not that I miss the fact, but rather I am taking a very broad => view of the user community. Someone told me once when I was playing => baseball for a league to not view the game from my position at 3rd base, => but view it from the perspective of all tHe posiitons maybe by watching => more baseball games in the grandstand and get off the infield once in => awhile. >Good advice. How about viewing it from the grandstand and getting off of >the host vendor position for a bit? I was by asking the questions. I do see several new points from your response. => I am not against variable addresses from a computer science perspective. => But am concerned as an engineer who will have to deliver a product thAt => tHe costs based on what I think the IPng enhanced function should => provide for the TCP/IP suite is reasonable and can be delivered within => an acceptable time-to-market window on a host. >A fine concern. Let's take your suggestion and be more detailed. In your >enumerated list of points above, it's clear that the cost is non-zero. But >it is not overwhelming either. [You didn't say that you COULDN'T POSSIBLY >implement it.] Can you quantify the costs in terms of nerd-clue-years? >For cisco, I'd say that the difference is about 1 nerd-clue-year, amortized >over the whole engineering department. Well if we can assume that its mostly transparent to all the applications then that would be great. This is an issue whether IPng is fixed or variable. I am going to propose this question to those who build the product. But my guess is about 1 nerd-clue-year and this would include a field test. But I still need to check performance costs I think on a host the hit is bigger than on other systems. I will also ask my PC wizards too, as I may get different answer than from the VMS and UNIX product host folks. >What are the benefits? Well, this is the tough one. I've been comparing >it to buying earthquake insurance in California. If you get hit by the Big >One, you Really need it. If you don't get hit, then it's a clear waste. >It's a risk that needs to be managed. The cost in the case that 16 bytes >are not enough are basically infinite. We have IPng++. We do this whole >thing again, and in the BEST case, it's our grandkids doing it. Good paragraph and food for thought. >What is the probability that we'll run out of 16 byte addresses? Well, >this is pretty subjective. But I think that everyone will agree that they >are non-zero. We certainly know that when IPv4 was designed and when the >telephone numbering system was designed, that they argued that there was >"enough" address space. They were both wrong. I think it is an act of >utter hubris to think that we'll do any better. For the sake of >discussion, let's say that the probability is 10% (I personally think it's >more like 90%). >Are you willing to live with the fact that the infrastructure we architect >today has a 10% chance of complete failure? No. And here is why. If we are to fail then we will know quickly because there are new markets chomping on the bit to use toasternet and they will break an invalid address design very quickly. This means I would have to re-invest in building a network kernel before I made any margins on my first engineering investement. But I am not convinced yet that variable addresses are necessary but must at least question whether 16bytes is enough given your response and this discussion. The big 10 header examples are only 16bytes. But they could be bigger based on the address length. The compromise might be to deploy IPng with 16bytes, but build the software so it can accomodate > 16bytes. >p.s. I'm sorta on vacation right now, so my replies may tend to lag a >bit. Have a good one we ain't gonna solve this before the next retreat. /jim From bound@zk3.dec.com Mon Jun 6 10:51:11 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA21857 for ; Mon, 6 Jun 1994 11:00:34 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA21791; Mon, 6 Jun 94 07:51:28 -0700 Received: by xirtlu.zk3.dec.com; id AA14157; Mon, 6 Jun 1994 10:51:17 -0400 Message-Id: <9406061451.AA14157@xirtlu.zk3.dec.com> To: tli@cisco.com, yakov@watson.ibm.com Cc: ipng@cmf.nrl.navy.mil Subject: Big 10 - Length and Locator Family Date: Mon, 06 Jun 94 10:51:11 -0400 X-Mts: smtp Why could we not put the length and locator family in the header and take it out of the address? This gives us full use of the address. For the locator family if I see in the header a family I can enter that code path for that family. thanks /jim From brian@dxcoms.cern.ch Mon Jun 6 17:49:08 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA22283 for ; Mon, 6 Jun 1994 11:49:45 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08895; Mon, 6 Jun 1994 17:49:10 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07045; Mon, 6 Jun 1994 17:49:09 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406061549.AA07045@dxcoms.cern.ch> Subject: Re: re An Architecture for BigTen Address Allocation To: tli@cisco.com (Tony Li) Date: Mon, 6 Jun 1994 17:49:08 +0200 (MET DST) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, tli@cisco.com, yakov@watson.ibm.com In-Reply-To: <199406031735.KAA18746@lager.cisco.com> from "Tony Li" at Jun 3, 94 10:35:43 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1399 Tony, I accept all your comments on my comments. I'll try to write a coherent note about changing providers and auto config, asap. Brian >--------- Text sent by Tony Li follows: > > > Brian, > > I have one global point: > > Nothing must happen to my internal addressing scheme when I change service > provider, or if my corporate network is multi-homed on several service > providers. As far as I can see this imposes a constraint that it must be > possible to distinguish the prefix from the rest of the address by > inspection. > > On an architectural level, I'm not sure I agree with this requirement. > When you change providers, you will end up changing prefixes. I don't > think that anything with topological sensitivity can change this. The > interesting case is if you change to a longer prefix. If your existing > internal addressing scheme still fits within the bounds of your > previous address length and perhaps you lose some unused reserved > bits within your prior addressing scheme, then you have a trivial > isomorphism (e.g., take out byte 10, shift our internal addresses > right one byte). > > If you can't fit, then yes, you're forced to a longer address length. > But you now have enough space so that you again have a trivial > isomorphism (e.g., shift our internal addresses right 8 bytes). > > Now some more detailed points: > (etc) From ericf@atc.boeing.com Mon Jun 6 09:02:12 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA22396 for ; Mon, 6 Jun 1994 12:00:17 -0400 Received: by atc.boeing.com (5.57) id AA21322; Mon, 6 Jun 94 09:02:12 -0700 Date: Mon, 6 Jun 94 09:02:12 -0700 From: Eric Fleischman Message-Id: <9406061602.AA21322@atc.boeing.com> To: Brian.Carpenter@cern.ch, tli@cisco.com Subject: Re: re An Architecture for BigTen Address Allocation Cc: ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com Dear Brian and Tony: Given John Curran's explanation at BIG 10 that in the general case provider based addressing will tie addresses to providers but, for a fee, different providers will route to users' using other providers addresses, it appears to me that we can have our cake and eat it too. That is, I firmly agree with Brian that the addresses used to address devices in end users' companies "belong to" those companies. It costs money to readdress and for large sites far too much money to make it conceivable except for upmost emergencies. However, neither Brian or I are blind to the demands of router aggregation. Thus, I think that John's arguments are the only solution to this knotty problem. The problem simply is that if anyone thinks that large users will necessarily readdress their vast deployments merely because they switched Internet Service providers then that "anyone" has a few surprises in store. Among other things it would imply that the addresses to which the user has been assigned were not delegated to that user but rather were only "loaned" and really belong to the providers. If this is what you are arguing for, Tony, then please loan me a table so that I could pound my shoe on it. If the community really wants all addresses to belong to the providers and not to the users, then that will also mean that we never could really get rid of our gateways even if we had exemplary security because we would continue to need them to map between our actual internal addressing and whatever addresses the Internet thinks we are using. Let's face it: strict provider-based addressing is end-user hostile and thus tends to alienate Internet users from Internet providers. Frankly, if this is the best approach our community can come up with then we are in a heap of trouble. Sincerely yours, --Eric Fleischman BRIAN: I have one global point: BRIAN: Nothing must happen to my internal addressing scheme when I change service BRIAN: provider, or if my corporate network is multi-homed on several service BRIAN: providers. As far as I can see this imposes a constraint that it must BRIAN: be possible to distinguish the prefix from the rest of the address by BRIAN: inspection. TONY: On an architectural level, I'm not sure I agree with this requirement. TONY: When you change providers, you will end up changing prefixes. I don't TONY: think that anything with topological sensitivity can change this. The TONY: interesting case is if you change to a longer prefix. If your existing TONY: internal addressing scheme still fits within the bounds of your TONY: previous address length and perhaps you lose some unused reserved TONY: bits within your prior addressing scheme, then you have a trivial TONY: isomorphism (e.g., take out byte 10, shift our internal addresses TONY: right one byte). From deering@parc.xerox.com Mon Jun 6 11:18:04 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA23480; Mon, 6 Jun 1994 14:19:34 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14618(8)>; Mon, 6 Jun 1994 11:18:29 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 6 Jun 1994 11:18:18 -0700 To: Allison J Mankin , sob@harvard.edu Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: 2nd IPNG Workshop--Outcome In-reply-to: mankin's message of Fri, 03 Jun 94 17:26:03 -0800. <199406040026.UAA04422@radegond.cmf.nrl.navy.mil> Date: Mon, 6 Jun 1994 11:18:04 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun6.111818pdt.12171@skylark.parc.xerox.com> Allison and Scott, I can participate on Monday only, and will do so from the West Coast. I will probably not be up-to-date on the preceding two week's worth of email, and my body will think it's still in the Central Europe time zone. I suggest that Bob Hinden, Bob Gilligan, Erik Nordmark, and Ran Atkinson be invited for both days; if that's too many outsiders, then exclude one or both of Gilligan and Nordmark. Steve From scoya@CNRI.Reston.VA.US Mon Jun 6 18:33:47 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA25389 for ; Mon, 6 Jun 1994 18:34:51 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10470; 6 Jun 94 18:33 EDT To: ipng@cmf.nrl.navy.mil Subject: IPNG Retreat part deux Date: Mon, 06 Jun 94 18:33:47 -0400 From: Steve Coya Message-ID: <9406061833.aa10470@IETF.CNRI.Reston.VA.US> Greetings, Am trying to prepare a list of who will be participating iin the retreat... along with the location per person. Here is what I have so far... please let me know your plans and I will consolodate for the entire directorate. Steve ============================================================ Scott Bradner Yes Boston Allison Mankin Yes Boston J Allard, Mircosoft ??? Steve Bellovin, AT&T No Jim Bound, DEC Yes Boston Ross Callon, Wellfleet Yes Boston Brian Carpenter, CERN Yes Boston Dave Clark, MIT Yes Boston Jon Crowcroft, UCL ??? John Curran, NEARnet Yes Boston Steve Deering, Xerox PARC Yes Bay Area Dino Farinacci, Cisco Yes Bay Area Eric Fleischman, Boeing No Paul Francis, NTT No Frank Kastenholz, FTP ??? Mark Knopper, Ameritech ??? Greg Minshall, Novell Yes Boston Craig Partridge, BBN ??? Rob Ullmann, Lotus ??? Lixia Zhang, Xerox PARC Yes Boston From tli@cisco.com Tue Jun 7 01:01:58 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id EAA27853 for ; Tue, 7 Jun 1994 04:02:36 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA11252; Tue, 7 Jun 1994 01:01:58 -0700 Date: Tue, 7 Jun 1994 01:01:58 -0700 From: Tony Li Message-Id: <199406070801.BAA11252@lager.cisco.com> To: Brian.Carpenter@cern.ch Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, tli@cisco.com, yakov@watson.ibm.com In-Reply-To: Brian Carpenter CERN-CN's message of Mon, 6 Jun 1994 17:49:08 +0200 (MET DST) <9406061549.AA07045@dxcoms.cern.ch> Subject: re An Architecture for BigTen Address Allocation I accept all your comments on my comments. I'll try to write a coherent note about changing providers and auto config, asap. Thanks Brian. I also said that I would think harder on your proposal for an alternate solution to the multihoming problem. I have some pretty strong concerns about the poor address space utilization that this would institutionalize. Basically you're multiplying the amount of address space used by the domain by the number of different external domains it's connected to. I understand that the benefit is a great deal of flexibility, but I am deeply concerned, roughly in inverse proportion to the amount of address space that we decide IPng can support. As this is in flux.... It _does_ occur to me that your approach would work nicely if it is not taken to its full extreme and is used in a hybrid with another solution. For example, suppose I chose Solution 2 (get prefixes from each provider, use the local prefix for the "local" systems) and then decided to "dual home" only the nodes which have a substantial amount of traffic to multiple external providers. This (unfortunately) also requires that the routing infrastructure support multiple prefixes. I can conceive of topologies where this is either trivial or impractical. ;-( I would welcome further thoughts, notes, or text on this, either on or off-line. Tony From tli@cisco.com Tue Jun 7 01:17:29 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id EAA27955 for ; Tue, 7 Jun 1994 04:18:04 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA11602; Tue, 7 Jun 1994 01:17:29 -0700 Date: Tue, 7 Jun 1994 01:17:29 -0700 From: Tony Li Message-Id: <199406070817.BAA11602@lager.cisco.com> To: ericf@atc.boeing.com Cc: Brian.Carpenter@cern.ch, tli@cisco.com, ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com In-Reply-To: Eric Fleischman's message of Mon, 6 Jun 94 09:02:12 -0700 <9406061602.AA21322@atc.boeing.com> Subject: re An Architecture for BigTen Address Allocation Eric, Thus, I think that John's arguments are the only solution to this knotty problem. The problem simply is that if anyone thinks that large users will necessarily readdress their vast deployments merely because they switched Internet Service providers then that "anyone" has a few surprises in store. Among other things it would imply that the addresses to which the user has been assigned were not delegated to that user but rather were only "loaned" and really belong to the providers. If this is what you are arguing for, Tony, then please loan me a table so that I could pound my shoe on it. I'm tempted, simply for good camcorder footage. ;-) But no, that's not what I was (pretty foggily) saying. I _do_ expect that when you change providers that you will end up changing prefixes. But I suspect that you will do so only because John's periodic bill for advertising your our-of-provider address space will become annoying and some bean-counter in accounting will ask you why. At some point, I suspect that folks will find the recurring charge unjustifiable. If I'm wrong, then you're just additional noise in the routing system. ;-( I do believe that this issue highlights why we have to have an action item/design requirement to make renumbering within IPng painless. IMHO, a good design for auto-addressing should include this capability. In the worst case, I would expect that it would mean manual reconfiguration of routers, probably in two passes. In the best case, it's trivial. TONY: On an architectural level, I'm not sure I agree with this requirement. TONY: When you change providers, you will end up changing prefixes. I don't TONY: think that anything with topological sensitivity can change this. The TONY: interesting case is if you change to a longer prefix. If your existing TONY: internal addressing scheme still fits within the bounds of your TONY: previous address length and perhaps you lose some unused reserved TONY: bits within your prior addressing scheme, then you have a trivial TONY: isomorphism (e.g., take out byte 10, shift our internal addresses TONY: right one byte). Tony From tli@cisco.com Tue Jun 7 02:11:44 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id FAA28155 for ; Tue, 7 Jun 1994 05:16:18 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA12396; Tue, 7 Jun 1994 02:11:44 -0700 Date: Tue, 7 Jun 1994 02:11:44 -0700 From: Tony Li Message-Id: <199406070911.CAA12396@lager.cisco.com> To: bound@zk3.dec.com Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil In-Reply-To: bound@zk3.dec.com's message of Mon, 06 Jun 94 10:32:44 -0400 <9406061432.AA13411@xirtlu.zk3.dec.com> Subject: re An Architecture for BigTen Address Allocation Jim, Whats the maximum routes at any one router point Cisco has seen today (maybe from ALE work we know this too)? We've seen 20k routes today. Depending on connectivity, the currently deployed high-end hardware can probably handle around 80k routes (wild-assed guess, emphasis on WILD). Its seems big enough if no individual router has to know of all routes for the IPng Internet which I will assume is the case? Sorry, there will always be some router which cannot point default. A trivial proof by contradiction is left as an exercise to the reader. => The 2bytes for subneting are only local to a private site like BBN, => XYZ, or CERN. Don't you believe 64K of address space is enough space => for private subnets at a site? >No, not a chance. cisco itself has multiple class B's. And we're TINY >compared to some of our customer networks. Need some clarity here. If you aggregate 16bits thats 64K subnets. Cisco has more than 64K subnets? No, we have more than 64k host addresses. Yes, I know of networks where more than 64k subnets will be required. You have answered this question above. I was asking why can't we just aggregate 32bits to support 4 billion addresses, instead of abstracting the hierarchy as in the draft. Now I would ask that the limitations of routers present memory (20 bits) be added to the draft so we understand why what I suggest is not feasible today. Also the search on a potential 32bit aggregate could be quite consuming as you pointed out. We are still dealing with hardware limitations. If I can find the time I will try to see how fast I can do a 32bit aggregate search on an Alpha just for grins. I'm loathe to enscribe our current hardware shortcomings in an architecture document to be handed down for future generations. Do YOU put dirty laundry in a time-capsule? ;-) I would guesstimate that we could do (today) 1us if we could add enough memory without slowing access. I would guesstimate that the Alpha, with everything in cache, would be an order of magnitude faster. As neither of us is likely to build the appropriate memory structures anytime soon, I suspect that the question is now moot and that the performance of both processors is wholly constrained by memory speed and size. The second part was the issue of supporting multiple address formats. Today with IPv4 I have multiple class addresses. When I receive them thats OK if an A talks to a B as you said I don't care. But all is well because each of them are 4bytes. It makes the software neat and clean and balanced and everything is aligned. What I am concerned about is having to parse address X as an incoming connection and my address type is Y with different length addresses. For example one is a 6byte 802 address and another is a 10byte xxx address. This gets to why EIDs are good. Make all node IDs for processing above the network layer say 8 bytes. I don't care about the routing state just the node ID when not dealing with a routing code path. It makes it much more simple. Got it. But EIDs must be globally unique. Good luck. If you come up with a solution, please let us know. >I'll make one point: we aren't designing IPng for today's hardware. Nor >today's software. Well I am? Yes, I think so. What you're telling me is that you're not willing to do variable length because you're not willing to change basic algorithms within the kernel. We know such algorithms must exist in general, as OSI hosts DO exist. This is a key issue I think for us to understand to reach consensus. If we need to be constrained for initial deployment because of a component of the network implementation such as a router or terminal server as examples then we need to absorb that into our technical solution for IPng. I would strongly suggest that while this may be a constraint for INITIAL deployment, that it should NOT be a constraint on the architecture. Our children should NOT have to pay for our inadequacies. [Only our incompetencies. ;-)] Doing this to just make the existing environment work would be a quick hack true for a prototype. But to build an OS network product we would have to spend much time restructuring to support my previous points regarding changes to the kernel. And that does have great costs. I still fail to see that things need to be restructured. I do see that interfaces need to be changed, but the basic functionality within the kernel should be sufficiently abstract (and it was, the last time I looked at BSD & SunOS) that there must be some re-implementation. I still don't see this as a "great" cost. Can you give us more concrete cost estimates? For example, for cisco, I would guess that IPng implementation will require 15 nerd-clue-years of work. As I mentioned before, variable length support has a marginal cost of about 1 nerd-clue-year. => I think => if variable addresses were accepted not to many host vendors would go => this route because the ramifications could be more costly than => re-structuring their network OS kernel subsystems. At least for the => first several years of IPng deployment. I can't speak for other host vendors but we have implemented 4.4 and can handle either 4.3 (no length field) or 4.4 (with length field), but no one is really using it for IPv4 to my knowledge. So we have not seen the ramifications at this time on caching, control blocks, queues, etc being based on variable addresses and the list in my previous response. Just because Berkeley added the sa_len field does not mean anyone is using it. It can be used in a SIPP prototype (see most recent SIPP API spec). But this is only a socket address and permits other protocols besides TCP/IP from the API build other than 32bit address architectures within a Berkeley kernel. What was not done is change all the structures or even add typedefs to the kernel to support a varible infrastructure for the network kernel. This would have to be done for IPng if incoming and outgoing connections became variable. The bottom line is no one is looking at the sa_len field extension to process IPv4 packets. The sa_len does permit us to set up an array of 4 or 8 byte addresses for IPng. Presently in SIPP we can treat the first 8 bytes as an identifying address the additional 8byte addresses for extended routing are available to the network layer if needed incoming or outgoing. The issue is now adding a length to determine the search. This is avoided with fixed length addresses. I not only have to load a length value but design a way to key off of variable structures or strings unless I put all types in the same queue and use multiple queues depending on the big 10 locator type which is the way I think may be most efficient. But you don't just go in and change a Berkeley kernel this way without verifying what it does to the rest of the system. So what Berkeley did was provide the ability to evolve towards variable addresses not implement a kernel that has been changed to support variable address structures. So what you're telling me is that Berkeley kernels have lots of protocol-specific information, data structures, and even algorithms in them which are designed specifically for IPv4 addresses. They can be easily stretched for longer fixed addresses, but when things go variable, then all of these now-unfounded assumptions fail. Further, while this is really just a Berkeley problem, enough host vendors depend on a Berkeley basis to make it likely that the host vendors would not transition to IPng. Is that a fair description of the argument? >As a router vendors we also manipulate addresses. Lots of 'em. >Frequently. Yes, we see that there is an _incremental_ additional cost to >variable length addresses. However, that cost is quite small and is very >much up front in training the programmers to live with a new paradigm. >Mortgaging the future of the Internet or spending two weeks of programmer >time is a relatively straightforward choice for us. What is so very >different for the host vendor community? I think the difference is the scope of the operating system inter-dependencies. Its not just re-training the programmers to deal with variable addresses its altering the network subsystem to deal with variable addresses. We for example made a large investment similar to this when we went from a BSD kernel to an OSF/1 kernel (BSD extended), and then within a close proximity from a 32bit machine architecture to a 64bit machine architecture. It was more than two weeks of training and required a lot of design work. You don't know what your facing until you begin changing a kernel for networking. For example many folks used the fact that a pointer was 32bits and hence an IPv4 address can be a pointer type. Well when your pointer becomes 64bits it breaks. Or when you went to 16 bytes, it breaks. This isn't a variable length problem. These are problems you don't think about until you begin to make the upgrade. Now I admit if all engineering was done properly much of the pain that might happen with variable addresses should not happen. But that unfortuneately is not reality. Ill behaved software exists everywhere. Often to gain performance. What I'm taking from this is that the reality is that the current software architecture is limited. And that we should design IPng, our network architecture for the next generation, based on the pain of fixing some ill behaved software. You would be roasting me on a spit if I suggested that we limit the IPng architecture based on cisco's software or hardware. Well variable addresses would be a new addition. In addition the changes required, which we are discussing, there is still the performance issue of checking length fields. It might be good to get some kind of hard analysis on this, and I am working on this now at my end. I see it as a few additional instructions. It will certainly be absorbed by the next generation of hardware. This, IMHO, is certainly not a constraint. >A fine concern. Let's take your suggestion and be more detailed. In your >enumerated list of points above, it's clear that the cost is non-zero. But >it is not overwhelming either. [You didn't say that you COULDN'T POSSIBLY >implement it.] Can you quantify the costs in terms of nerd-clue-years? >For cisco, I'd say that the difference is about 1 nerd-clue-year, amortized >over the whole engineering department. Well if we can assume that its mostly transparent to all the applications then that would be great. This is an issue whether IPng is fixed or variable. I am going to propose this question to those who build the product. But my guess is about 1 nerd-clue-year and this would include a field test. Well, if that's the case, then I think that this is a non-issue, and you should just invest the additional energy. This is NOT a big deal. But I still need to check performance costs I think on a host the hit is bigger than on other systems. I will also ask my PC wizards too, as I may get different answer than from the VMS and UNIX product host folks. Ok. >Are you willing to live with the fact that the infrastructure we architect >today has a 10% chance of complete failure? No. And here is why. If we are to fail then we will know quickly because there are new markets chomping on the bit to use toasternet and they will break an invalid address design very quickly. This means I would have to re-invest in building a network kernel before I made any margins on my first engineering investement. But I am not convinced yet that variable addresses are necessary but must at least question whether 16bytes is enough given your response and this discussion. The big 10 header examples are only 16bytes. But they could be bigger based on the address length. The compromise might be to deploy IPng with 16bytes, but build the software so it can accomodate > 16bytes. That's exactly what the WHOLE key to variable length addresses is. If "The Big One" never hits and we never blow out of the 16 bit address space, then we've simply paid a couple of nerd-clue-years in insurance. Cheap at twice the price. Why could we not put the length and locator family in the header and take it out of the address? This gives us full use of the address. ? We need to route on the locator family and (probably) the length. Moving them elsewhere makes routing much harder. For the locator family if I see in the header a family I can enter that code path for that family. a) You shouldn't need a separate code path for each family right now. With the possible exception of multicast. The other case is that of another host with an imbedded address of another protocol family. I don't see what needs to happen differently here, for a pure IPng host. b) Is there some reason that you can't see the LF while it's where it is? Tony From bound@zk3.dec.com Wed Jun 8 13:20:56 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA03180 for ; Wed, 8 Jun 1994 13:32:01 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA13441; Wed, 8 Jun 94 10:21:24 -0700 Received: by xirtlu.zk3.dec.com; id AA12638; Wed, 8 Jun 1994 13:21:02 -0400 Message-Id: <9406081721.AA12638@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: final FIRP rpt available Date: Wed, 08 Jun 94 13:20:56 -0400 X-Mts: smtp ------- Forwarded Message Return-Path: hovey@wnpv01.ENET.dec.com Received: by xirtlu.zk3.dec.com; id AA14700; Tue, 7 Jun 1994 11:51:01 -0400 Date: Tue, 7 Jun 1994 11:51:01 -0400 Message-Id: <9406071551.AA14700@xirtlu.zk3.dec.com> From: hovey@wnpv01.ENET.dec.com (Standards & Consortia, DCC 07-Jun-1994 1149) To: bound@xirtlu.ENET.dec.com Cc: HOVEY Subject: final FIRP rpt available - -------- From: US4RMC::"nakassis@osi.ncsl.nist.gov" "Tassos Nakassis" 7-JUN-1994 11:48:09.76 To: T5@osf.org, attendees.oiw@sst.ncsl.nist.gov, division@sst.ncsl.nist.gov, fnc@nsipo.arc.nasa.gov, ietf@cnri.reston.va.us CC: nakassis@osi.ncsl.nist.gov Subj: FIRP Report Now Available from NIST The Report of the Federal Internetworking Requirements Panel (dated 31 May 1994) is available at (and from) NIST. The report can be obtained as follows: (1) Anonymous file transfer can be achieved through FTP, FTAM and Gopher. The files available are: * firp-report.asc Flat ASCII version * firp-report.doc Microsoft Word for Windows version (IBM PC). * firp-report.Hqx BinHex version (for Macintosh Word/MacDraw) as transmitted by the editor. * firp-report.ps A PostScript version of the report * firp-report.rtf A Rich Text Format (RTF) version of the report. * firp-report.wp A WordPerfect 5.1 (for DOS) version of the report. The approximate size of these files is: * firp-report.asc 160 Kbytes * firp-report.doc 172 Kbytes * firp-report.Hqx 269 Kbytes * firp-report.ps 1935 Kbytes * firp-report.rtf 235 Kbytes * firp-report.wp 199 Kbytes The NIST staff is currently investigating the production of a smaller PostScript version of the report. Please note that all files were derived directly or indirectly from the file transmitted by the editor; but, insofar as the original version contained characters that only the Macintosh-Word editor supports and diagrams, adjustments have been made. In addition, please note that paper copies created out of these files may not have the same pagination as the editor's copy and that page references in the text may be incorrect. Each firp-report.* file has an f-report.* equivalent so as to accommodate those who prefer names of length eight at most. For anonymous FTP: 1. ftp to osi.ncsl.nist.gov (129.6.48.100) 2. respond to the "login:" prompt with user name "anonymous" (do not type the quotes) 3. respond to the "password:" prompt with your E-mail address. 4. you are now logged in. Use "cd" to change directory to ./pub/firp. Use "ls" or "dir" to get directory listings. Use "get" to transfer a file. For anonymous FTAM: Paddr = {1,1,1,47:0005:80:005A00:0000:0001:E137:080020079EFC:00} userid = anon, no password, realstore = unix The corresponding "ISODE isoentities" entry is: osi.ncsl.nist.gov filestore NULL \ #1/#1/#1/NS+47000580005a0000000001e137080020079efc00 Questions regarding these services should be sent via SMTP mail to staff@osi.ncsl.nist.gov. (2) Copies available through electronic mail Send e-mail to mail-server@osi.ncsl.nist.gov and specify in the message FILE /pub/firp/x.y where x=firp-report or f-report and y=asc, Hqx, rtf, or ps. If one of the binary files (y=doc,wp) is desired, preceed the file command with the encoding command as follows: ENCODING uuencode FILE /pub/firp/firp-report.doc This will result in a uuencoded version of the file being e-mailed back to you. Note that will not be useful unless you have the uudecode program. (3) Paper Copies: Paper copies of the report are available from Joan Wyrwa, Technology Building, Room B217, NIST, Gaithersburg, MD 20899; telephone: (301) 975-3643; facsimile: (301) 590-0932. (4) Other: If you experience problems, please contact Joan Wyrwa (wyrwa@osi.ncsl.nist.gov, (301) 975-3643). Tassos Nakassis ------- End of Forwarded Message From bound@zk3.dec.com Wed Jun 8 14:27:54 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA04217 for ; Wed, 8 Jun 1994 15:37:03 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA16837; Wed, 8 Jun 94 11:28:16 -0700 Received: by xirtlu.zk3.dec.com; id AA14413; Wed, 8 Jun 1994 14:28:01 -0400 Message-Id: <9406081828.AA14413@xirtlu.zk3.dec.com> To: tli@cisco.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au Cc: bound@zk3.dec.com Subject: Whats the Motivation for Variable Addresses ?? Date: Wed, 08 Jun 94 14:27:54 -0400 X-Mts: smtp Hi Folks, I have a few questions. I am looking at this technically right now for a host and its cost. I still owe Tony a response but bear with me I still have a few more lines of code to check in 4.4. But I also have now talked to a couple of busines people and technical leader types in my company and out of my company too. When I proposed lets do EIDs people said what are they and define them. Well thats getting done and Frank has gotten us off in tHe right direction I think. But I need to ask the same thing of variable adddress in a different context. What is the motivation for variable addresses? Do we think we can build products without limits? Do we think we can know what technology will be required 10 years from now for this very new networking market now emerging? Should host vendors absorb this additional cost to support variable addresses? Why should hosts want to do this what business benefit is there for them to perform this engineering? It don't matter if its 1 day, 1 person year, or 10 person years, you do not incur costs without a valid reason in engineering. Can variable addresses be managed as well as fixed length addresses? As a comment I have heard almost all operators I ask state that fixed addreeses are easier to manage, especially the University environment. Your comments on this I think would be useful to my quest to an objective outcome of this topic. thanks /jim From sob@hsdndev.harvard.edu Wed Jun 8 15:54:06 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA04316; Wed, 8 Jun 1994 15:55:57 -0400 Date: Wed, 8 Jun 94 15:54:06 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406081954.AA14088@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch, bound@zk3.dec.com Subject: Re: 2nd IPNG Workshop--Outcome Cc: ipng@cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil The hotels in the Harvard Sq area are: *sorry no phone #s, I'm in Prague) The Sheraton Commander The Charles Hotel The Inn at Harvard The cambridge Marriott is 2 stops away on the subway. Scott From sob@hsdndev.harvard.edu Wed Jun 8 16:20:56 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA04611 for ; Wed, 8 Jun 1994 16:24:48 -0400 Date: Wed, 8 Jun 94 16:20:56 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406082020.AA15745@hsdndev.harvard.edu> To: Bob.Hinden@eng.sun.com, atkinson@itd.nrl.navy.mil, bound@zk3.dec.com, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com, yakov@watson.ibm.com Subject: Re: Whats the Motivation for Variable Addresses ?? one reason for var length addresses was just mentioned on big-i. if one has 16 Byte addresses as the basic address and wants to support source routing the resulting header could get quite large. esp. if what one wanted to do in the source route was to do cluster or provider routing which might not require a full node address to define. Scott From tli@cisco.com Wed Jun 8 13:54:31 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id QAA04826 for ; Wed, 8 Jun 1994 16:59:20 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA06652; Wed, 8 Jun 1994 13:54:31 -0700 Date: Wed, 8 Jun 1994 13:54:31 -0700 From: Tony Li Message-Id: <199406082054.NAA06652@lager.cisco.com> To: bound@zk3.dec.com Cc: yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Wed, 08 Jun 94 14:27:54 -0400 <9406081828.AA14413@xirtlu.zk3.dec.com> Subject: Whats the Motivation for Variable Addresses ?? Hi Folks, Hi Jim, At the risk of boring everyone to tears, I'll reply... What is the motivation for variable addresses? We aren't fortune tellers. We cannot accurately predict the future with any degree of certainty. We can make some educated guesses about how much address space we need, but without building it and living with an Internet architecture, we really have no idea if it will work over its entire lifespan. Because the cost of failure is catastrophic (we run out of address space and the network stops growing), it would be nice to engineer in a large safety factor for the address space. Just making the addresses a whole lot longer would work, but it would have a prohibitive cost in that everyone would need to pay the overhead of carrying extremely long addresses all the time. Making the address variable length means that we can use shorter addresses now, and only go to longer addresses if we need them. Do we think we can build products without limits? No, of course not. But that's not what we're suggesting, either. Variable length addresses are not infinite. And while products may have limits today, hopefully those product limits are beneath the limits of the architecture and not vice-versa. Do we think we can know what technology will be required 10 years from now for this very new networking market now emerging? With any precision? No. However, it is reasonable to assume that datagram based traffic is not going to go away anytime soon and may well become the lingua franca of the future. If that were to happen, we would not want to become obsolete because we didn't plan on being successful. Should host vendors absorb this additional cost to support variable addresses? Why should hosts want to do this what business benefit is there for them to perform this engineering? It don't matter if its 1 day, 1 person year, or 10 person years, you do not incur costs without a valid reason in engineering. More generally, is this additional architectural cost worthwhile? Yes, it's cheap insurance against guessing too small at the size of the address space. The business benefit is having an IP architecture which is not limited by its own success. Can variable addresses be managed as well as fixed length addresses? As a comment I have heard almost all operators I ask state that fixed addreeses are easier to manage, especially the University environment. Yes, they can. Variable length addresses have the length encoded in them, so that you can determine the length by simple inspection of the address. Further, if we decide to route based on this length field (as seems likely at this point), the individual site administrator only ever sees a single address length for his local network. The fact that the individual administrators don't realize that we're actually doing routing based on variable length prefixes today indicates how well we're doing at making it easy for them (and how poorly we're doing at educating them ;-(). Tony From kre@munnari.OZ.AU Thu Jun 9 07:06:55 1994 Return-Path: kre@munnari.OZ.AU Received: from munnari.oz.au (munnari.OZ.AU [128.250.1.21]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA04920 for ; Wed, 8 Jun 1994 17:12:56 -0400 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20998; Thu, 9 Jun 1994 07:06:59 +1000 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: tli@cisco.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Wed, 08 Jun 1994 14:27:54 -0400." <9406081828.AA14413@xirtlu.zk3.dec.com> Date: Thu, 09 Jun 1994 07:06:55 +1000 Message-Id: <22229.771109615@munnari.OZ.AU> From: Robert Elz Date: Wed, 08 Jun 94 14:27:54 -0400 From: bound@zk3.dec.com Message-ID: <9406081828.AA14413@xirtlu.zk3.dec.com> What is the motivation for variable addresses? It gives people a warm fuzzy feeling that the addresses can grow large enough to cope with anything that might arise, and thus perhaps encourages, or at least allows, a smaller starting point than would be required with fixed size addresses. (ie: if we know we can grow to hundreds of bytes if we need to, we may be able to start at 8 now, otherwise we're probably going to have to start bigger - even if it turns out that 8 would have been enough when we eventually look back with hindsight). It allows people to create truly large and obscenely wasteful addressing schemes without inflicting that on the rest of the world. Do we think we can build products without limits? I don't do much product building, but no, of course not. I don't think I've even seen anyone propose a truly variable length address, which would require either a variable length length field (like asn.1), or self delimiting addresses (flag bytes or something). Even the most rabid variable length enthusiasts seem content with the (rather small) max size of 255 bytes (length field fits in a byte). Should host vendors absorb this additional cost to support variable addresses? That cost is comparatively trivial - real question is whether we users should absorb the effeciency loss in processing the things - that will go on forever. Even with the best possible special casing of the "standard" length, testing for that must cost, and there's no guarantee that such a standard length would remain standard for long at all. Can variable addresses be managed as well as fixed length addresses? As a comment I have heard almost all operators I ask state that fixed addreeses are easier to manage, especially the University environment. Fixed addresses are easier to manage well - variable length addresses are probably easier to manage badly. kre From lixia@parc.xerox.com Wed Jun 8 14:59:05 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA05164 for ; Wed, 8 Jun 1994 18:00:13 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14825(2)>; Wed, 8 Jun 1994 14:59:23 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 8 Jun 1994 14:59:15 -0700 Date: Wed, 8 Jun 1994 14:59:05 PDT Sender: Lixia Zhang From: Lixia Zhang To: ipng@cmf.nrl.navy.mil Subject: Re: 2nd IPNG Workshop--Outcome In-Reply-To: Your message of Wed, 8 Jun 1994 12:54:06 -0700 Message-ID: > The hotels in the Harvard Sq area are: *sorry no phone #s, > I'm in Prague) > > The Sheraton Commander > The Charles Hotel > The Inn at Harvard > > The cambridge Marriott is 2 stops away on the subway. - Would some on in Boston be kind enough to get the phone #s for these places? - For everyone flying to Boston: do we want to all pick the same place to stay? From Greg_Minshall@Novell.COM Wed Jun 8 19:59:43 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA06339 for ; Wed, 8 Jun 1994 23:03:19 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA09805; Wed, 8 Jun 94 21:02:25 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB05023; Wed, 8 Jun 94 19:59:43 PDT Date: Wed, 8 Jun 94 19:59:43 PDT Message-Id: <9406090259.AB05023@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: re An Architecture for BigTen Address Allocation Cc: ipng@cmf.nrl.navy.mil Jim, >But EIDs must be globally unique. I don't think you can have globally unique EIDs which autoconfigure (based, possibly, on info on the wire, like the prefix) in 8 bytes. And, i think EIDs need to be handed out in the same way as locators (in terms of administrative slop, etc.). And, i don't see anything wrong with longer-sized (locator == id sized) EIDs, especially at the transport layer. Greg From bound@zk3.dec.com Wed Jun 8 23:26:07 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA06456 for ; Wed, 8 Jun 1994 23:35:24 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA11873; Wed, 8 Jun 94 20:26:26 -0700 Received: by xirtlu.zk3.dec.com; id AA23027; Wed, 8 Jun 1994 23:26:13 -0400 Message-Id: <9406090326.AA23027@xirtlu.zk3.dec.com> To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Wed, 08 Jun 94 13:54:31 PDT." <199406082054.NAA06652@lager.cisco.com> Date: Wed, 08 Jun 94 23:26:07 -0400 X-Mts: smtp Tony, >At the risk of boring everyone to tears, I'll reply... Hmmm hold back... dont flame ... ouch ouch.. OK I am cool. So far we have done this in a nice way. Lets keep the momentum if we can. Its a reveiw process which is the essence of the Directorate. Thanks though I know its hard. => What is the motivation for variable addresses? >We aren't fortune tellers. We cannot accurately predict the future >with any degree of certainty. We can make some educated guesses about >how much address space we need, but without building it and living >with an Internet architecture, we really have no idea if it will work >over its entire lifespan. I agree. So maybe as another Directorate member suggested if we can only figure it out for the next 5 years lets build it and get on with the design. And we will have to fix it again in 5 years from the time we deploy it. Not bad for a product cycle in our industry. >Because the cost of failure is catastrophic (we run out of address >space and the network stops growing), it would be nice to engineer in >a large safety factor for the address space. Just making the >addresses a whole lot longer would work, but it would have a >prohibitive cost in that everyone would need to pay the overhead of >carrying extremely long addresses all the time. Making the address >variable length means that we can use shorter addresses now, and only >go to longer addresses if we need them. Well this is a good time to get into the costs. First the kernel costs are at least six months from the time we pick IPng. But, thats not the only cost. We have to change the APIs and make sure that its compatible with IPv4 in a binary fashion (at least I believe this is an IPng Transition Requirement). Then we need to look at DHCP, BOOTP, SNMP, DNS, and all the applications that do not check for variable lengths. Ah see this is why an EID is so great. The EID can be a fixed transport address and the routing sequence can be variable. => Do we think we can build products without limits? >No, of course not. But that's not what we're suggesting, either. >Variable length addresses are not infinite. And while products may >have limits today, hopefully those product limits are beneath the >limits of the architecture and not vice-versa. I do admit this part of variable addresses intrigues me greatly. If we don't think 128bits are enough for example for the next 10-15 years then this argument has much strength. I am not sure networks will last longer. In fact I am not sure I will either. => Do we think we can know what technology will be required 10 years from => now for this very new networking market now emerging? With any precision? No. However, it is reasonable to assume that datagram based traffic is not going to go away anytime soon and may well become the lingua franca of the future. If that were to happen, we would not want to become obsolete because we didn't plan on being successful. If we break the MTUs with oversized packets again maybe a datagram protocol is not what IPng should be looking at but rather some form of connection set up. => Should host vendors absorb this additional cost to support variable => addresses? Why should hosts want to do this what business benefit => is there for them to perform this engineering? It don't matter if => its 1 day, 1 person year, or 10 person years, you do not incur => costs without a valid reason in engineering. >More generally, is this additional architectural cost worthwhile? >Yes, it's cheap insurance against guessing too small at the size of >the address space. The business benefit is having an IP architecture >which is not limited by its own success. Good point. Its a little more expensive than our first conversations now. Also Dave Katz is correct it is in BSD 4.4. But not all host vendors picked up that version because it was work to make it compatible with 4.3 fyi. => Can variable addresses be managed as well as fixed length addresses? As => a comment I have heard almost all operators I ask state that fixed => addreeses are easier to manage, especially the University environment. >Yes, they can. Variable length addresses have the length encoded in >them, so that you can determine the length by simple inspection of the >address. Further, if we decide to route based on this length field >(as seems likely at this point), the individual site administrator >only ever sees a single address length for his local network. The >fact that the individual administrators don't realize that we're >actually doing routing based on variable length prefixes today >indicates how well we're doing at making it easy for them (and how >poorly we're doing at educating them ;-(). I still think the length field should be in the header and the locator family. Here is why. Before I begin to process the variable address I can from the header know its lengths and type of IPng family (CLNP or IPX encapsulated or foo.addr.from.me, etc.). This can also be used by the host (type of IPng packet => locator family) during transition. thanks for the continued discussion, /jim From bound@zk3.dec.com Wed Jun 8 23:48:51 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA06538 for ; Wed, 8 Jun 1994 23:51:08 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA13163; Wed, 8 Jun 94 20:49:08 -0700 Received: by xirtlu.zk3.dec.com; id AA23167; Wed, 8 Jun 1994 23:48:57 -0400 Message-Id: <9406090348.AA23167@xirtlu.zk3.dec.com> To: Greg Minshall Cc: ipng@cmf.nrl.navy.mil Subject: Re: re An Architecture for BigTen Address Allocation In-Reply-To: Your message of "Wed, 08 Jun 94 19:59:43 PDT." <9406090259.AB05023@WC.Novell.COM> Date: Wed, 08 Jun 94 23:48:51 -0400 X-Mts: smtp Greg, =>But EIDs must be globally unique. >I don't think you can have globally unique EIDs which autoconfigure (based, >possibly, on info on the wire, like the prefix) in 8 bytes. And, i think >EIDs need to be handed out in the same way as locators (in terms of >administrative slop, etc.). Not without a server that I can come up with I agree. But if the IEEE 802 address is used in IPng exclusively as a local-use only address than thats OK. A local-use only address cannot be used for any off LAN connections. This could emulate an EID until the node either goes to a IPng DHCP server for its global autoconfiguration address or to DNS to register its name where DNS will then give the node its global EID address. If such a strategy would be used then we would be saying IEEE addresses are local-use only and cannot be made to be globally unique. About the best I can come up with as I thought of this too. >And, i don't see anything wrong with longer-sized (locator == id sized) >EIDs, especially at the transport layer. Well I don't either while we figure out what EIDs are unless we go with a variable address for IPng. Then an EID could possibly provide us a fixed transport address and a variable locator address which can be part of DNS data from gethostbyname on EID. I say this becasue it reduces the complexity of going to variable addresses by about 70%. I don't have to change the host network transport layer, a compatible IPng / IPv4 API can be built with no cost, and my applications 'may' not care now about the variable locator in most cases I can determine. Just some ideas for thought. /jim From tli@cisco.com Thu Jun 9 01:29:07 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id EAA07319 for ; Thu, 9 Jun 1994 04:33:45 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA12195; Thu, 9 Jun 1994 01:29:07 -0700 Date: Thu, 9 Jun 1994 01:29:07 -0700 From: Tony Li Message-Id: <199406090829.BAA12195@lager.cisco.com> To: bound@zk3.dec.com Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au In-Reply-To: bound@zk3.dec.com's message of Wed, 08 Jun 94 23:26:07 -0400 <9406090326.AA23027@xirtlu.zk3.dec.com> Subject: Whats the Motivation for Variable Addresses ?? Jim, Hmmm hold back... dont flame ... ouch ouch.. OK I am cool. So far we have done this in a nice way. Lets keep the momentum if we can. Its a reveiw process which is the essence of the Directorate. Thanks though I know its hard. My apologies if that sounded like a flame. It _really_ wasn't intended to be. [Geeze, what do I have to do, get stoned before sending mail?] I agree. So maybe as another Directorate member suggested if we can only figure it out for the next 5 years lets build it and get on with the design. And we will have to fix it again in 5 years from the time we deploy it. Not bad for a product cycle in our industry. It's not a product, it's an architecture. It needs a life cycle of much LONGER than 5 years. Certainly the last one was 10 years. Do we want to stand up and change all IP hosts again in 5 years? What would you think if your phone company said that you had to buy a new phone every 5 years? I do admit this part of variable addresses intrigues me greatly. If we don't think 128bits are enough for example for the next 10-15 years then this argument has much strength. I am not sure networks will last longer. In fact I am not sure I will either. ;-) I still think the length field should be in the header and the locator family. Here is why. Before I begin to process the variable address I can from the header know its lengths and type of IPng family (CLNP or IPX encapsulated or foo.addr.from.me, etc.). This can also be used by the host (type of IPng packet => locator family) during transition. Well, in that case, you'd need two of them, one for source locator and one for destination locator. And how do you deal with source routing??? Tony From bound@zk3.dec.com Thu Jun 9 08:49:42 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA08030 for ; Thu, 9 Jun 1994 08:58:01 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA13852; Thu, 9 Jun 94 05:50:07 -0700 Received: by xirtlu.zk3.dec.com; id AA00385; Thu, 9 Jun 1994 08:49:48 -0400 Message-Id: <9406091249.AA00385@xirtlu.zk3.dec.com> To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Thu, 09 Jun 94 01:29:07 PDT." <199406090829.BAA12195@lager.cisco.com> Date: Thu, 09 Jun 94 08:49:42 -0400 X-Mts: smtp Tony, => Hmmm hold back... dont flame ... ouch ouch.. OK I am cool. => So far we have done this in a nice way. Lets keep the momentum if we => can. Its a reveiw process which is the essence of the Directorate. => Thanks though I know its hard. >My apologies if that sounded like a flame. It _really_ wasn't >intended to be. [Geeze, what do I have to do, get stoned before >sending mail?] OK I am beng to sensitive and also learning email tone with different folks. When I read this at 6:30 a.m. I laughed so hard I spilled my coffee all over my self. Good one. Friend asked me if I was going to Woodstock II, as I am in New England, this August. I told him no cause to many will be drunk and violent this time around. Probably won't be a peace chant. Anyway .... => I agree. So maybe as another Directorate member suggested if we can => only figure it out for the next 5 years lets build it and get on with => the design. And we will have to fix it again in 5 years from the time => we deploy it. Not bad for a product cycle in our industry. >It's not a product, it's an architecture. It needs a life cycle of >much LONGER than 5 years. Certainly the last one was 10 years. Do we >want to stand up and change all IP hosts again in 5 years? What would >you think if your phone company said that you had to buy a new phone >every 5 years? I do think 128bits could last us into 2005. I don't think redoing IP again then is unreasonable. If we can believe this then fixed addresses of 16bytes is plenty for 10 years. Giving us until 1995 to see first incantations of IPng in the market. I think a product manager would not have heart burn with that. For 5 years they may. => I still think the length field should be in the header and the locator => family. Here is why. Before I begin to process the variable address I => can from the header know its lengths and type of IPng family (CLNP or IPX => encapsulated or foo.addr.from.me, etc.). This can also be used by the => host (type of IPng packet => locator family) during transition. >Well, in that case, you'd need two of them, one for source locator and >one for destination locator. And how do you deal with source routing??? Well you got me thar. I was just looking at the incoming packet on demux. But now that you said this it does make me now want to think about APIs when one address is x bits and another address y bits a little closer. Putting it in the address will keep the header smaller too. Source route. Yep this kills it completely. take care, /jim From bound@zk3.dec.com Thu Jun 9 15:58:54 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA10921 for ; Thu, 9 Jun 1994 16:00:34 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA13247; Thu, 9 Jun 94 12:59:11 -0700 Received: by xirtlu.zk3.dec.com; id AA13369; Thu, 9 Jun 1994 15:59:00 -0400 Message-Id: <9406091959.AA13369@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Retreat Beantown Hotel phone numbers Date: Thu, 09 Jun 94 15:58:54 -0400 X-Mts: smtp The Sheraton Commander (617) 547-4800 The Charles Hotel (617) 864-1200 The Inn at Harvard (617) 491-2222 /jim From bound@zk3.dec.com Thu Jun 9 16:05:19 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA10962 for ; Thu, 9 Jun 1994 16:10:12 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA13687; Thu, 9 Jun 94 13:05:37 -0700 Received: by xirtlu.zk3.dec.com; id AA13548; Thu, 9 Jun 1994 16:05:25 -0400 Message-Id: <9406092005.AA13548@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Oh.. I here the commander hotel is much cheaper .. Date: Thu, 09 Jun 94 16:05:19 -0400 X-Mts: smtp From rcallon@pobox.wellfleet.com Thu Jun 9 17:48:26 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA11593 for ; Thu, 9 Jun 1994 17:52:52 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22574; Thu, 9 Jun 94 17:51:24 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA16533; Thu, 9 Jun 94 17:48:26 EDT Date: Thu, 9 Jun 94 17:48:26 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9406092148.AA16533@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil, scoya@cnri.reston.va.us Subject: Re: IPNG Retreat part deux Am trying to prepare a list of who will be participating iin the retreat... along with the location per person. Here is what I have so far... please let me know your plans and I will consolodate for the entire directorate. Steve ============================================================ I didn't see Bob Gilligan and Erik Nordmark on this list. Shouldn't they be present at least for the transition discussion on Sunday? Also, to what extent is this a Boston meeting with a few folks calling in from elsewhere, versus a meeting in two locations (Boston and Palo Alto), with an equal number of folks in each location? Will we be telephone conferenced, or videoconferenced? The reason that I ask is that I was expecting to miss the Monday meeting due to having to be at a Monday dinner meeting in San Francisco. However, if the meeting is really a two-site pretty much equally tied in meeting, then I could fly out Saturday, and would be able to attend in Palo Alto until about 3pm Monday. Ross From brian@dxcoms.cern.ch Fri Jun 10 10:29:39 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA13635 for ; Fri, 10 Jun 1994 04:30:14 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22494; Fri, 10 Jun 1994 10:29:39 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA18445; Fri, 10 Jun 1994 10:29:39 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406100829.AA18445@dxcoms.cern.ch> Subject: Re: Retreat Beantown Hotel phone numbers To: ipng@cmf.nrl.navy.mil Date: Fri, 10 Jun 1994 10:29:39 +0200 (MET DST) In-Reply-To: <9406091959.AA13369@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jun 9, 94 03:58:54 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 261 Thanks Jim. Do all the out-of-towners agree on the Commander? Brian >--------- Text sent by bound@zk3.dec.com follows: > > The Sheraton Commander (617) 547-4800 > The Charles Hotel (617) 864-1200 > The Inn at Harvard (617) 491-2222 > > /jim > From tli@cisco.com Fri Jun 10 02:29:38 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id MAA16115 for ; Fri, 10 Jun 1994 12:15:13 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA16657; Fri, 10 Jun 1994 02:29:38 -0700 Date: Fri, 10 Jun 1994 02:29:38 -0700 From: Tony Li Message-Id: <199406100929.CAA16657@lager.cisco.com> To: bound@zk3.dec.com Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au In-Reply-To: bound@zk3.dec.com's message of Thu, 09 Jun 94 08:49:42 -0400 <9406091249.AA00385@xirtlu.zk3.dec.com> Subject: Whats the Motivation for Variable Addresses ?? Jim, I do think 128bits could last us into 2005. I don't think redoing IP again then is unreasonable. If we can believe this then fixed addresses of 16bytes is plenty for 10 years. Giving us until 1995 to see first incantations of IPng in the market. I think a product manager would not have heart burn with that. For 5 years they may. Well, I recall that the IPng charter suggests that we design for 20 years. Me, I'm not so confident. I want a safety pad. I'm trying to design for 40. I figure I can still miss by 50% and succeed. ;-) Tony From lixia@parc.xerox.com Fri Jun 10 07:00:04 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA15017 for ; Fri, 10 Jun 1994 10:01:10 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14422(1)>; Fri, 10 Jun 1994 07:00:22 PDT Received: by redwing.parc.xerox.com id <57153>; Fri, 10 Jun 1994 07:00:16 -0700 Date: Fri, 10 Jun 1994 07:00:04 PDT Sender: Lixia Zhang From: Lixia Zhang To: ipng@cmf.nrl.navy.mil Subject: Re: Retreat Beantown Hotel phone numbers In-Reply-To: Your message of Fri, 10 Jun 1994 01:29:39 -0700 Message-ID: > Thanks Jim. Do all the out-of-towners agree on the Commander? > > Brian I just made the reservation there. it is not cheap ($135/night :-( ) Lixia From brian@dxcoms.cern.ch Fri Jun 10 17:44:13 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA15858 for ; Fri, 10 Jun 1994 11:44:48 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12534; Fri, 10 Jun 1994 17:44:14 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02283; Fri, 10 Jun 1994 17:44:13 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406101544.AA02283@dxcoms.cern.ch> Subject: Re: Retreat Beantown Hotel phone numbers To: ipng@cmf.nrl.navy.mil Date: Fri, 10 Jun 1994 17:44:13 +0200 (MET DST) In-Reply-To: from "Lixia Zhang" at Jun 10, 94 06:58:39 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 509 Lixia, how did you do it? They quoted me $160. I told them your name. They said "that was an error" but gave me the $135 rate :-) This would NEVER happen in Europe. America is great. BTW they do not have a shuttle from Logan. Is there a poor people's way of getting there? Brian >--------- Text sent by Lixia Zhang follows: > > > Thanks Jim. Do all the out-of-towners agree on the Commander? > > > > Brian > > I just made the reservation there. it is not cheap ($135/night :-( ) > > Lixia > From Bob.Hinden@Eng.Sun.COM Fri Jun 10 12:17:00 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA17771 for ; Fri, 10 Jun 1994 15:24:35 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24429; Fri, 10 Jun 94 12:23:18 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA22601; Fri, 10 Jun 94 12:23:21 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA27315; Fri, 10 Jun 1994 12:17:00 -0700 Date: Fri, 10 Jun 1994 12:17:00 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406101917.AA27315@jurassic.Eng.Sun.COM> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: Bob.Hinden@Eng.Sun.COM, atkinson@itd.nrl.navy.mil, bound@zk3.dec.com, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com, yakov@watson.ibm.com In-Reply-To: <9406082020.AA15745@hsdndev.harvard.edu> Subject: Re: Whats the Motivation for Variable Addresses ?? Scott, > one reason for var length addresses was just mentioned on big-i. > if one has 16 Byte addresses as the basic address and wants to > support source routing the resulting header could get quite > large. esp. if what one wanted to do in the source route > was to do cluster or provider routing which might not require > a full node address to define. It is possible to do this without going to an IPng with variable length addresses. The cluster addresses can be compressed in the routing header. This works because the main header always has room for two max sized addresses. It requires another pointer in the routing header to keep track of where to swap in the next address. I don't think the additional complexity in the routing header is worth it to save space because authentication will be needed when using loose source route (cluster/provider) style routing. The authentication info will not be small. Variable length addresses are not needed for this. Bob From bound@zk3.dec.com Fri Jun 10 18:33:16 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA18719 for ; Fri, 10 Jun 1994 18:37:13 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA16855; Fri, 10 Jun 94 15:33:36 -0700 Received: by xirtlu.zk3.dec.com; id AA12045; Fri, 10 Jun 1994 18:33:22 -0400 Message-Id: <9406102233.AA12045@xirtlu.zk3.dec.com> To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Fri, 10 Jun 94 02:29:38 PDT." <199406100929.CAA16657@lager.cisco.com> Date: Fri, 10 Jun 94 18:33:16 -0400 X-Mts: smtp Hi Tony, Well I am burned out on this now. But I think what I have gotten as consensus at my end is this. If we can make 128bits work in SIPP then there is no reason to incur any costs of variable addresses. But if 128bits will not work from 15-20 years then we should go to variable addresses on hosts and absorb the costs. Right now I think 128bits is enough to do that. If CIDR is predicting that 4 bytes can be arranged to support us until 2005, then certainly 16bytes can last us until 2015. Which is 20 years. Right now I am not convinced we should support variable addresses on hosts. I cannot justify the cost increase in my mind no matter how great or minimal that cost is as an engineer. One input as to how long will it be acceptable to make this architecture work is to determine how long will it take us to migrate the installed IPv4 base to IPng? Another input is that I was told by several folks that most of the traffic for our customers is on the LAN. Why are we incurring so much overhead in IPng?. For routing. Think about it in telnet you can transmit just an echo character on a LAN. If our datagram protocol is going to grow without bounds (no pun intended) then connecton setup for Hosts on a LAN seem like a very valid idea. I hope discussion gets started on Big-I. My last comment (I hope) on all if this is that we did not put convergence as a requirement in the IPng requirements. Yet it seems to be a part of Big-10. The IPng requirements document had a review period and convergence did not make it as a requirement. Lets be careful we don't re-enact Kobe again in the community. I think I could call foul and the paper trail is not congruent with the Big-10 drafts statements about protocol use within IPng. But I won't because I think if it can be done as a side affect of good technical design thats great. But it should not drive the technical design, which is the jist of the present IPng requirements document, and why I believe we did not have consensus to put convergence in the requirements document. /jim From mankin@radegond.cmf.nrl.navy.mil Fri Jun 10 18:55:08 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id SAA18833 for ; Fri, 10 Jun 1994 18:55:10 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id SAA00814 for ; Fri, 10 Jun 1994 18:55:08 -0400 Message-Id: <199406102255.SAA00814@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil Subject: Getting to Harvard Square from the airport Date: Fri, 10 Jun 94 18:55:08 -0400 From: Allison J Mankin The cheap and easy way (sort of, at leasat it moves, in contrast to cars and taxis) is to take the T (subway). A bus stops outside the terminals to take you to Airport Station. Inside you pay $1.00 (I think) and take the inbound car to Government Center. Take the Green Line there to Park Street. Take the Red Line there to Harvard Square. It also is not too costly to pick up a cab to the Commander from the Government Center station instead of hauling the rest of the way on public transportation. Good luck, all. We'll have to set up some times and send out a map for how to get to Pierce Hall. Allison From smb@research.att.com Fri Jun 10 20:35:17 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id WAA19420 for ; Fri, 10 Jun 1994 22:37:38 -0400 From: smb@research.att.com Message-Id: <199406110237.WAA19420@picard.cmf.nrl.navy.mil> Received: by gryphon; Fri Jun 10 20:35:18 EDT 1994 To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: Retreat Beantown Hotel phone numbers Date: Fri, 10 Jun 94 20:35:17 EDT Lixia, how did you do it? They quoted me $160. I told them your name. They said "that was an error" but gave me the $135 rate :-) This would NEVER happen in Europe. America is great. BTW they do not have a shuttle from Logan. Is there a poor people's way of getting there? The T -- the Boston subway line -- runs to Logan airport, with the help of a shuttle bus. From tli@cisco.com Sat Jun 11 00:25:38 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id DAA21947 for ; Sat, 11 Jun 1994 03:30:36 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA18128; Sat, 11 Jun 1994 00:25:38 -0700 Date: Sat, 11 Jun 1994 00:25:38 -0700 From: Tony Li Message-Id: <199406110725.AAA18128@lager.cisco.com> To: bound@zk3.dec.com Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au In-Reply-To: bound@zk3.dec.com's message of Fri, 10 Jun 94 18:33:16 -0400 <9406102233.AA12045@xirtlu.zk3.dec.com> Subject: Whats the Motivation for Variable Addresses ?? Jim, If CIDR is predicting that 4 bytes can be arranged to support us until 2005, then certainly 16bytes can last us until 2015. Is this really all you want to aspire to with a new architecture? To recall a trite beer commercial: you only go around once. If our datagram protocol is going to grow without bounds (no pun intended) then connecton setup for Hosts on a LAN seem like a very valid idea. Fine, but that brings us into the realm of flows, and we're no longer talking about addressing. My last comment (I hope) on all if this is that we did not put convergence as a requirement in the IPng requirements. Yet it seems to be a part of Big-10. The IPng requirements document had a review period and convergence did not make it as a requirement. Lets be careful we don't re-enact Kobe again in the community. I think I could call foul and the paper trail is not congruent with the Big-10 drafts statements about protocol use within IPng. But I won't because I think if it can be done as a side affect of good technical design thats great. But it should not drive the technical design, which is the jist of the present IPng requirements document, and why I believe we did not have consensus to put convergence in the requirements document. Jim, I will happily stipulate that convergence is not a technical requirement for the IETF for IPng. However, several significant IETF players have a very large stake in getting convergence. I believe that the IETF also has a lot to gain by attracting a very large number of users from other protocols. So, yes, convergence is probably not a technical requirement. But it is a political/strategic/tactical/market requirement. Please consider that if we do not provide convergence from IPX to IPng, then Provo may simply provide convergence from IPv4 to IPXng. We would not be helping users. Provo would. IMHO, if we don't provide convergence, then we can just quit right now and let Provo do the grunt work, too. Tony p.s. Just so this is not misconstrued: I am in no way blackmailing the IETF on behalf of Novell. Nor am I privy to any internal discussions at Novell. I am simply trying to think through the business implications. I believe that Novell would PREFER us to provide convergence -- that way we do the grunt work. From kre@munnari.OZ.AU Sat Jun 11 18:38:33 1994 Return-Path: kre@munnari.OZ.AU Received: from munnari.oz.au (munnari.OZ.AU [128.250.1.21]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA22126 for ; Sat, 11 Jun 1994 04:43:13 -0400 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06800; Sat, 11 Jun 1994 18:38:36 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Sat, 11 Jun 1994 00:25:38 MST." <199406110725.AAA18128@lager.cisco.com> Date: Sat, 11 Jun 1994 18:38:33 +1000 Message-Id: <22479.771323913@munnari.OZ.AU> From: Robert Elz Date: Sat, 11 Jun 1994 00:25:38 -0700 From: Tony Li Message-ID: <199406110725.AAA18128@lager.cisco.com> If CIDR is predicting that 4 bytes can be arranged to support us until 2005, then certainly 16bytes can last us until 2015. Is this really all you want to aspire to with a new architecture? If we assume that the size of the internet doubles every 6 months, and continues at that rate, and that the current 32 bit address space is fully used up already, then the extra 96 bits should give us 48 years of growth. That's beyond 2040. All this requires is that we keep being at least as effecient in address allocation as we are now - which shouldn't be hard given what the practice has been in the past. About the only constraint would be that we not hand out 8 byte chunks to organisations that insist on sticking MAC addresses in 6 of them, wasting huge chunks of space (organisations that really are approaching having 2^48 hosts may warrant a 64 bit address space, no-one else does). Even wasting those 6 bytes completely, the 6 byte gain (from 4 bytes to 10) will give us at least 24 years (~2020), and probably longer as those 6 bytes wouldn't be completely wasted, you can probably assume an average of about 10 useful bits in those 48, for an extra 5 years (~2025). I also don't believe that doubling every 6 months can possibly continue, whatever happens, for anything like 30 years, if it continues (if its even anything like that rate now) for 5 years it would be truly astounding. So, yes, convergence is probably not a technical requirement. But it is a political/strategic/tactical/market requirement. Until someone shows how this mythical convergence works, I refuse to take any note of it at all. Simply sticking protocol X's addresses inside IPng addresses tells me nothing at all. To grow to IPng scales all of those other protocols (with the possible sole exception of CLNP if TUBA is adopted, but even there possibly excluding decnet-v, for what that is worth) are going to have to go through all the same pains as IPv4 is, and that's going to mean changing their addressing structure in any case (IPX's 4 byte net numbers with no addressing plan to speak of aren't going to last long). But even that is the easy part, things like IPX will need to work out how to find a service location protocol that scales to internet size before they're any kind of threat to anyone at all. kre From tli@cisco.com Sat Jun 11 01:47:51 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id EAA22140 for ; Sat, 11 Jun 1994 04:49:46 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA20295; Sat, 11 Jun 1994 01:47:51 -0700 Date: Sat, 11 Jun 1994 01:47:51 -0700 From: Tony Li Message-Id: <199406110847.BAA20295@lager.cisco.com> To: kre@munnari.OZ.AU Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil In-Reply-To: Robert Elz's message of Sat, 11 Jun 1994 18:38:33 +1000 <22479.771323913@munnari.OZ.AU> Subject: Whats the Motivation for Variable Addresses ?? Robert, If we assume that the size of the internet doubles every 6 months, and continues at that rate, and that the current 32 bit address space is fully used up already, then the extra 96 bits should give us 48 years of growth. That's beyond 2040. You are ignoring (as Dave Crocker is so fond of pointing out) paradigm shifts, which make this type of projection very dubious. Yes, I agree with him. Even wasting those 6 bytes completely, the 6 byte gain (from 4 bytes to 10) will give us at least 24 years (~2020), and probably longer as those 6 bytes wouldn't be completely wasted, you can probably assume an average of about 10 useful bits in those 48, for an extra 5 years (~2025). This is also very important. I also don't believe that doubling every 6 months can possibly continue, whatever happens, for anything like 30 years, if it continues (if its even anything like that rate now) for 5 years it would be truly astounding. Running out of addresses if the astounding happens makes us look astoundingly stupid. So, yes, convergence is probably not a technical requirement. But it is a political/strategic/tactical/market requirement. Until someone shows how this mythical convergence works, I refuse to take any note of it at all. Simply sticking protocol X's addresses inside IPng addresses tells me nothing at all. To grow to IPng scales all of those other protocols (with the possible sole exception of CLNP if TUBA is adopted, but even there possibly excluding decnet-v, for what that is worth) are going to have to go through all the same pains as IPv4 is, and that's going to mean changing their addressing structure in any case (IPX's 4 byte net numbers with no addressing plan to speak of aren't going to last long). But even that is the easy part, things like IPX will need to work out how to find a service location protocol that scales to internet size before they're any kind of threat to anyone at all. As I've pointed out previously, the migration path for IPX is pretty simple and straightforward. First, you prepend some number of bits of topologically sensitive information which makes the address unique to a particular IPX address space. Now, you deploy IPng software on IPX servers within that domain, and configure them to use their IPX addresses while speaking IPng. The great advantage of this is that the end user has one single address space to administer, used by both network layer protocols. Note that this does not propose running inter-domain IPX, so inter-domain SAP is not even an issue. Tony From kre@munnari.OZ.AU Sat Jun 11 20:05:47 1994 Return-Path: kre@munnari.OZ.AU Received: from munnari.oz.au (munnari.OZ.AU [128.250.1.21]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id GAA22267 for ; Sat, 11 Jun 1994 06:11:03 -0400 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09222; Sat, 11 Jun 1994 20:05:50 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Sat, 11 Jun 1994 01:47:51 MST." <199406110847.BAA20295@lager.cisco.com> Date: Sat, 11 Jun 1994 20:05:47 +1000 Message-Id: <22507.771329147@munnari.OZ.AU> From: Robert Elz Date: Sat, 11 Jun 1994 01:47:51 -0700 From: Tony Li Message-ID: <199406110847.BAA20295@lager.cisco.com> You are ignoring (as Dave Crocker is so fond of pointing out) paradigm shifts, which make this type of projection very dubious. Yes, I agree with him. No, in this case I'm not (well, maybe sidestepping slightly). Its possible such a thing may happen, and it may consume lots of address space - even if such a thing were to appear at any point, and consume 100 times the previously allocated address space, all that is is 7 bits worth - 3.5 years on the doubling every 6 months theory. Personally I don't see anything like that happen in some big rush, but even if it did, the effect would be to make it considerably harder to keep doubling every 6 months. I refuse to accept continuous new paradigm shifts every few years that continually grab huge multiples of the address space allocated to that time, that's beyond the unlikely and into the absurd. The only way that current exponentail growth can be sustained is to have it find some nice stable usage that keeps growing and keep growing with it. I actually find it hard to imagine long term continued growth rates greater than about 10% a year once most of the population gets covered - which largely means getting networking through Asia. Even wasting those 6 bytes completely, This is also very important. I agree, we need to take pains to make sure that we don't allow this absurd MAC address in the locator demand. If mac addresses are to be permitted there, why not phone numbers (for slip/ppp or isdn). I believe that international numbers are set to move to 18 digits (from 15). With binary encoding, that's 60 bits - with bcd (the way NSAP's would do it), its 72. Why not? (No, I'm not suggesting that these things be used for actually dialing the phone, any more than MAC addresses would be used for transmission on a LAN - but they are an existing allocated number space, complete with hierarchy). Running out of addresses if the astounding happens makes us look astoundingly stupid. No, no more than the IPv4 designers look astoundingly stupid. As long as we make a best effort to play for reasonable growth, and then some more, that's all that can be asked. 128 bits is more than we're ever going to rationally be able to make use of - we just need to make rational allocations. No address space (not even 255 byte NSAP's) can cope with lunacy. 128 bits allocated rationally is lots more space than is available in NSAP's. I did have some reservations with 64 bits - though only small ones, that I think would probably be enough to last as long as we care about (once something else obsoletes IPng it no longer matters). 128 bits is plenty. Really. The great advantage of this is that the end user has one single address space to administer, used by both network layer protocols. This is a help - once the users understand that they will have to renumber all their existing IPX in order to get this benefit. Without fiddling IPX servers at all, users can get basically the same benefit by simply taking the low 4 bytes of their "network number" part of their IPng address, and using it as the IPX net number - which is more or less what I believe that many IPX sites do now (using their IPv4 numbers). Note that this does not propose running inter-domain IPX, so inter-domain SAP is not even an issue. Do you really believe that Novell are about to implement new server code, and get people to upgrade to it, for no benefit beyond letting people share net numbers? Doesn't seem likely. Why isn't Greg Minshall getting all this mail? If its not obvious, I'm not convinced. kre From tli@cisco.com Sun Jun 12 00:58:51 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id DAA25138 for ; Sun, 12 Jun 1994 03:59:41 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA28979; Sun, 12 Jun 1994 00:58:51 -0700 Date: Sun, 12 Jun 1994 00:58:51 -0700 From: Tony Li Message-Id: <199406120758.AAA28979@lager.cisco.com> To: kre@munnari.OZ.AU Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil In-Reply-To: Robert Elz's message of Sat, 11 Jun 1994 20:05:47 +1000 <22507.771329147@munnari.OZ.AU> Subject: Whats the Motivation for Variable Addresses ?? Robert, It occurs to me that it's NOT clear that we can continue to do as well as we have with IPv4 address allocation. Please recall that addressing efficiency falls with each hierarchical level. Currently, IPv4 basically has two levels: subnet and network. CIDR is trying to make it three. Looking at BigTen, we're going to probably have 6 to 8 levels. Thus, addressing efficiency could decrease significantly. Tony From kre@munnari.OZ.AU Sun Jun 12 19:11:32 1994 Return-Path: kre@munnari.OZ.AU Received: from munnari.oz.au (munnari.OZ.AU [128.250.1.21]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id FAA25359 for ; Sun, 12 Jun 1994 05:46:45 -0400 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17426; Sun, 12 Jun 1994 19:11:37 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Sun, 12 Jun 1994 00:58:51 MST." <199406120758.AAA28979@lager.cisco.com> Date: Sun, 12 Jun 1994 19:11:32 +1000 Message-Id: <22553.771412292@munnari.OZ.AU> From: Robert Elz Date: Sun, 12 Jun 1994 00:58:51 -0700 From: Tony Li Message-ID: <199406120758.AAA28979@lager.cisco.com> Please recall that addressing efficiency falls with each hierarchical level. Yes. Currently, IPv4 basically has two levels: subnet and network. Some of us actually have multiple levels of subnet - we have 3 here (4 I guess if you include p2p wires) - that is, the basic subnets are 255.255.255.0, we also use 255.255.255.192 and 255.255.255.240 - and I think the p2p's (which I don't deal with personally) are set at 255.255.255.252. All that hierarchy actually gains us effeciency (without it we'd have been out of subnets and needing more net numbers ages ago). But I understand what you're getting at. Looking at BigTen, we're going to probably have 6 to 8 levels. I have read half of it - briefly - six sounds reasonable to me, 8 possible, but can probably be avoided. If we tried hard, I think we could manage with 5 or 6 (excluding internal subnetting inside organisations). Thus, addressing efficiency could decrease significantly. It could decrease a little, especially initially, however as the address space begins to be used all that hierarchy will actually help, and effeciency will improve - just as its doing now with IPv4. Do remember that its not the past few years of allocations I was considering, but the whole of IPv4, including back when anyone or their dog could get a class A (and still own it now), and the vast majority of allocations, when everyone simply applied for and received class B's. Its that kind of thing that really wastes address space, as spaces allocated to end users are gone forever. On the other hand, ranges ear-marked for providers can continue to be allocated till they run out, and if we're careful how we do allocations, they can even be reclaimed if we discover that New Zealand really never needed the 2^30 nets we initially allocated to them (that's a number I just invented for purposes of example) - doing that may decrease routing effeciency a little, but not a lot. Its at the user end we need to be careful though, so allocate address spaces to organisations only on the basis of likely reasonable need, rather than greed (my life will be easier if I can have all those millions of bits...) kre From bound@zk3.dec.com Sun Jun 12 21:11:36 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA27202 for ; Sun, 12 Jun 1994 21:16:42 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA22031; Sun, 12 Jun 94 18:11:59 -0700 Received: by xirtlu.zk3.dec.com; id AA04140; Sun, 12 Jun 1994 21:11:42 -0400 Message-Id: <9406130111.AA04140@xirtlu.zk3.dec.com> To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.OZ.AU Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Sat, 11 Jun 94 00:25:38 PDT." <199406110725.AAA18128@lager.cisco.com> Date: Sun, 12 Jun 94 21:11:36 -0400 X-Mts: smtp Tony, > If CIDR is predicting that 4 bytes can be arranged to support us > until 2005, then certainly 16bytes can last us until 2015. >Is this really all you want to aspire to with a new architecture? The host kernel will not look the same in 2015. Yes I will take 20 years where the network layer address structure does not have to be changed. I could say I want NIMROD if I wanted to wait for IPng and that has even more benefit in my mind than fixing the address space. The address space is basic without it we can't go on. Tell me it can last for 20 years and yes I can live with that technically. Is this all I want? No much more but we need to get on here with IPng. And what I want is much more than variable addresses. But that is not going to happen. >To recall a trite beer commercial: you only go around once. No we will go around again I predict in 2010. Thats OK. > If our datagram protocol > is going to grow without bounds (no pun intended) then connecton setup > for Hosts on a LAN seem like a very valid idea. >Fine, but that brings us into the realm of flows, and we're no longer >talking about addressing. Yep another mailing list. A good one to I might add. > My last comment (I hope) on all if this is that we did not put > convergence as a requirement in the IPng requirements. Yet it seems to > be a part of Big-10. The IPng requirements document had a review period > and convergence did not make it as a requirement. Lets be careful we > don't re-enact Kobe again in the community. I think I could call foul > and the paper trail is not congruent with the Big-10 drafts statements > about protocol use within IPng. But I won't because I think if it can > be done as a side affect of good technical design thats great. But it > should not drive the technical design, which is the jist of the present > IPng requirements document, and why I believe we did not have consensus > to put convergence in the requirements document. >Jim, I will happily stipulate that convergence is not a technical >requirement for the IETF for IPng. However, several significant IETF >players have a very large stake in getting convergence. I believe >that the IETF also has a lot to gain by attracting a very large number >of users from other protocols. So, yes, convergence is probably not a >technical requirement. But it is a >political/strategic/tactical/market requirement. I don't think you need to stipulate that in your document. I stated that if you get that as a side benefit thats goodness. As long as we do not design IPng to be great because of convergence to any protocol (CLNP, IPX, SNA, DECnet, any of them). I won't get into an IPX, CLNP, SNA, or any discussion. I don't think its a good idea legally for any of us. I suggest unless your not a vendor that this line of discussion is very dangerous as this mail will be made available to the public. I have no comment on convergence other than it should not be a requirement at this time to select an IPng technical strategy. As far as the market I have no comment other than its all pure speculation. /jim From tli@cisco.com Sun Jun 12 18:29:16 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA27231 for ; Sun, 12 Jun 1994 21:33:51 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA29327; Sun, 12 Jun 1994 18:29:16 -0700 Date: Sun, 12 Jun 1994 18:29:16 -0700 From: Tony Li Message-Id: <199406130129.SAA29327@lager.cisco.com> To: bound@zk3.dec.com Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.OZ.AU In-Reply-To: bound@zk3.dec.com's message of Sun, 12 Jun 94 21:11:36 -0400 <9406130111.AA04140@xirtlu.zk3.dec.com> Subject: Whats the Motivation for Variable Addresses ?? Jim, > If CIDR is predicting that 4 bytes can be arranged to support us > until 2005, then certainly 16bytes can last us until 2015. >Is this really all you want to aspire to with a new architecture? Is this all I want? No much more but we need to get on here with IPng. Then why are we still discussing this? This topic is not delaying us, other than the discussion. Seems like a win-win situation to me. >To recall a trite beer commercial: you only go around once. No we will go around again I predict in 2010. Thats OK. No, that's the protocol. I'm talking about us, human beans. ;-) If we do go around again in 2010, it won't be us. As far as the market I have no comment other than its all pure speculation. Agreed. Of course, this is not completely wild speculation. There is some experience and reason here. Enough to cause me to lose sleep. ;-) Tony From bound@zk3.dec.com Sun Jun 12 22:43:23 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id WAA27401 for ; Sun, 12 Jun 1994 22:45:34 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA26566; Sun, 12 Jun 94 19:43:41 -0700 Received: by xirtlu.zk3.dec.com; id AA04613; Sun, 12 Jun 1994 22:43:29 -0400 Message-Id: <9406130243.AA04613@xirtlu.zk3.dec.com> To: Tony Li Cc: bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.OZ.AU Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Sun, 12 Jun 94 18:29:16 PDT." <199406130129.SAA29327@lager.cisco.com> Date: Sun, 12 Jun 94 22:43:23 -0400 X-Mts: smtp Tony, >Is this all I want? No much more but we need to get on here with >IPng. >Then why are we still discussing this? This topic is not delaying us, >other than the discussion. Seems like a win-win situation to me. Well I got some off line input that we need some more host related data still. The situation is this. I have determined that there are 6 places in a BSD kernel where I have to check for a variable address. These are just checks. At the datalink when I strip the packet from the ifnet interface, because I need to determine my memory requirement. At the network layer when I parse the network layer packet, and then at the transport on receive and send when I either build or check a protocol control block. With BSD 4.4 the routing cache entries use a variable address based on the extended sa_len field after a longest match. This has not been done for tcp or udp. Your inline function suggestion is one approach and there are others such as adding a structure with a dynamic pointer (garbage collection is assumed). The socket API can handle variable addresses using the new sa_len field but a bounded array would be better (like the 64bytes in Big-10 or the way we have done it for SIPP at present to support that extended address strategy). But in SIPP the identifying address would only be used for the transport set up. Hence, in most cases I don't have to look at the rest of the address at the transport layer. As a side note this is what makes only dealing with a transport identifer that is globally unique nice for a host and its applications interface. The rest of the network addresses in the packet can be present they are just not used at the API boundary or by the transport layer. This part being fixed length reduces complexity between the transport and application interface. I was hoping that the EID ideas in NIMROD could be moved into IPng, but I guess that could be an architecture discussion forever and we need to move on here. But if we had a fixed transport ID that would be very good. Similar to some of the routing requirements I have seen stated for efficiency in our discussions, but for a host. So most of the person-hour cost for beneath the application layer are adding variable length tests, changing cache, lists, and queue look ups, and setting up the communications domain variables to support a complete variable address structure from the transport layer down to the data link layer. The performance costs for you old assembler hacks is the extra length instruction look up to branch off the register. But this as best I can tell is not an order of magnitude performance loss at least on an Alpha. Obviously aligned fields are important to all at this point. This is how I came up with 1 engineer to alter the kernel for six months. OK its my best guess-estimate. This estimate is based on the fact that we have implemented 4.4 variable addresses for CLNP and IPv4 and dealt with the IPv4 compatibility issues. So that would extend the cost to any vendor who has not done BSD 4.4. My best guess is that is another 6 months as that was done as part of our upgrade and I can't get an exact answer as to how much time 4.4 took. So we are back to my 1-nerd-clue year. But I have not looked at and unfortuneately do not have the time to look at all the code that needs to change above the transport layer into the application layers. This affects apps like DNS because right now DNS deals with fixed length addresses. Same for any network application like SNMP, Mail, DHCP, et al. Not sure, but if I have time I can look at a few of the apps before the retreat. No promises though. I am in DNS anyway for SIPP and other related work so I will try. Now how did I come up with 128bits if it will work then we don't see the point of variable addresses? Basically this has been an extensive technical discussion internally because of me. After all the arguments pro and con consensus was that if 128bits meets the IPng requirements then there is no reason to do variable address. If you don't need a variable address then why do the work. But if 128bits do not meet the IPng requirements then IPng would be foolish to not use variable addresses. The issue is that at what limit does a variable address become worth any cost to the host. We have drawn the line in the sand at 128bits as my input to the IPng Directorate. This is my position based on what we know right now and the data I have seen presented and of course my own technical judgement. >No, that's the protocol. I'm talking about us, human beans. ;-) >If we do go around again in 2010, it won't be us. OK. > As far as the market I have no comment other than its all pure > speculation. >Agreed. Of course, this is not completely wild speculation. There is >some experience and reason here. Enough to cause me to lose sleep. Not me I lost sleep for many years in the operating system space. The network is the computer now. IPng will be the protocol that folks will use for wide scale interoperability that is Multi-Vendor. Unless we build a bad spec or to many additions that kill performance then I think IPng will be a protocol all vendors can use to connect their customers. There is one other thing that could kill IPng and that is a poor transition plan or one that will not work. I owe the directorate a high level list. Ah another task, which I have started. /jim From brian@dxcoms.cern.ch Mon Jun 13 11:17:54 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id FAA28643 for ; Mon, 13 Jun 1994 05:19:22 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24379; Mon, 13 Jun 1994 11:17:57 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02162; Mon, 13 Jun 1994 11:17:55 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406130917.AA02162@dxcoms.cern.ch> Subject: Re: Whats the Motivation for Variable Addresses ?? To: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 13 Jun 1994 11:17:54 +0200 (MET DST) Cc: tli@cisco.com, bound@zk3.dec.com, yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil In-Reply-To: <22479.771323913@munnari.OZ.AU> from "Robert Elz" at Jun 11, 94 06:38:33 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1861 Hmm... this thread seems to be on the IPng Directorate list plus some extra names... strange... >--------- Text sent by Robert Elz follows: ... > So, yes, convergence is probably not a technical requirement. > But it is a political/strategic/tactical/market requirement. > > Until someone shows how this mythical convergence works, I > refuse to take any note of it at all. Simply sticking protocol > X's addresses inside IPng addresses tells me nothing at all. > To grow to IPng scales all of those other protocols (with the > possible sole exception of CLNP if TUBA is adopted, but even > there possibly excluding decnet-v, for what that is worth) > are going to have to go through all the same pains as IPv4 > is, and that's going to mean changing their addressing structure > in any case (IPX's 4 byte net numbers with no addressing plan > to speak of aren't going to last long). But even that is the > easy part, things like IPX will need to work out how to find > a service location protocol that scales to internet size before > they're any kind of threat to anyone at all. > I just cannot get on your wavelength here, Robert. I've designed several addressing plans in my life and changing the addressing plan in an operating network is the real nightmare. I would LOVE to be able to map our IP, DECnet, IPX and AppleTalk addressing plans into a single addressing plan, and slowly migrate to a single addressing and routing architecture. The financial, technical, operational and sociological benefits of this are so obvious that I could scream. You're 100% correct that we also need scalable service location protocols. Shout and see if anybody answers doesn't scale. (Anybody else suffered from mixing ONC RPC v.2 and v.3 ?-) Brian P.S. You asked whether Greg Minshall is reading this thread. I expect he's too busy with IPXng :-) From bound@zk3.dec.com Mon Jun 13 08:35:08 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA29619 for ; Mon, 13 Jun 1994 08:41:19 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA25925; Mon, 13 Jun 94 05:35:29 -0700 Received: by xirtlu.zk3.dec.com; id AA11086; Mon, 13 Jun 1994 08:35:14 -0400 Message-Id: <9406131235.AA11086@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil, Bob.Gilligan@eng.sun.com Subject: Transition Questions to help define the requirements Date: Mon, 13 Jun 94 08:35:08 -0400 X-Mts: smtp These questions can help us understand what the issues are for transitiion. Some could become requirements other will be abstractions to define requirements. If folks start sending input I will keep it in a folder and try to coalesce it before the retreat. /jim --------------------------------------------------------------------- Will end user customers require incremental solutions to move to IPng in many cases? Should transition be separated into several independent more focused transitions? - Applications Transition - End System Transition - Interior Routing Transition - Exterior Routing Transition Is having the old IPv4 address space mapped to a part of the new IPng address space a good idea? Should exisiting APIs for IPv4 should maintain binary compatibility once IPng is turned on? Should Administration and Configuration of the Transition be defined clearly and with details? Will supporting both IPng and IPv4 network layers on End Systems ease the transition? What are the alterations to TCP and UDP to support IPng Transition? What are the changes to DNS to support IPng Transition? What applications will be affected by IPng bigger addresses? What existing network tools are/can be used to manage the Transition? What new tools are needed to to manage the Transition? What are the changes to the APIs? Should encapsulation be used for transition (why/where)? Should translation be used for transition (why/where)? What parts of IPng must be deployed on the Internet if any before transition can begin? What are the requirements for providers to support IPng Transition? Should customers be able to begin transition at the end system or at the routing domain for IPng? Will IPng only systems exist that do not contain an IPv4 network layer? Should routing control parameters be used to support transition? Should transition encourage a movement to IPng only routing domains? During transition what will motivate customers to move to IPng as their backbone routing protocol to replace IPv4? What are the cost trade-offs for different Transition scenarios? What is the end user perspective on transition? What is the routers vendor perspective on transition? WHat is the operators perspective on transition? What is the providers perspective on transition? Does IPng system discovery have a role to play in IPv4 to IPng transition? Does IPng autoconfiguration have a role to play in IPv4 to IPng transition? What are the performance requirements of transition for each system in the network? /jim From atkinson@sundance.itd.nrl.navy.mil Mon Jun 13 07:56:22 1994 Return-Path: atkinson@sundance.itd.nrl.navy.mil Received: from sundance.itd.nrl.navy.mil (sundance.itd.nrl.navy.mil [132.250.92.89]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA29352 for ; Mon, 13 Jun 1994 07:57:50 -0400 From: Ran Atkinson Message-Id: <9406130756.ZM16164@sundance.itd.nrl.navy.mil> Date: Mon, 13 Jun 1994 07:56:22 -0500 In-Reply-To: Tony Li "Whats the Motivation for Variable Addresses ??" (Jun 11, 0:25) References: <199406110725.AAA18128@lager.cisco.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: Tony Li , bound@zk3.dec.com Subject: Re: Whats the Motivation for Variable Addresses ?? Cc: yakov@watson.ibm.com, ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com, dkatz@cisco.com, atkinson@itd.nrl.navy.mil, kre@munnari.oz.au Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil Folks, I very much agree with Jim Bound on this. There is significant support for the notion that we can get at least 20 years out of a 16 byte address. With "serverless autoaddressing" taking up 6 bytes, then there are at least 10 bytes/20 nibbles/80 bits available for routing heirarchy, which is MUCH more than all of the IPv4 address space. If one were to spend a byte on "convergence", then there is still plenty of address space and heirarchy to make it to 2015 with comfort. We've locally concluded that although variable length addresses can certainly be implemented, they are not completely trivial to implement. 4.4 BSD (actually I think Net/2 and later ?) supports arbitrarily variable length addresses through the sockets interface glue code. It does not however support arbitrarily variable length addresses throughout the stack. BSD appears to assume that an NSAP can never be larger than 20 octets, for example. I agree that it is difficult to justify ANY amount of extra work when we can see that it is not necessary for the agreed-upon goal. I keep thinking about this "convergence" question and continue to have trouble with the notion that address translation is always useful. For example, the local AppleTalk topology here is NOT the same as the local IP topology. I can see the value of address translation as a transition aid in certain circumstances. However, the IETF will need to write clear guidance on how to safely use address translation and when to avoid its use. I think Ross Callon might have good insights on this question from his past experiences. I think it is incumbent on those advocating "address translation" to devise and document a scheme that has minimal impact on other areas. An IPX or AppleTalk system can use "serverless autoaddressing" to get an IPng address. Why would they always desire to use address translation ? To me, this seems to fall out as a stronger justification for "serverless autoaddressing" rather than for "address translation". Note that I'm not per se objecting to address translation; I just see issues that haven't (IMHO) been adequately addressed to date. I think it is extremely important that we keep in mind the agreed-upon goals and not incrementally add requirements or get side-tracked. If we can't retain focus on the agreed-upon goals, then we are unlikely to have a useful IPng. Ran atkinson@itd.nrl.navy.mil From Greg_Minshall@Novell.COM Mon Jun 13 16:31:26 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA05307 for ; Mon, 13 Jun 1994 19:38:45 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA02180; Mon, 13 Jun 94 17:34:40 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB17919; Mon, 13 Jun 94 16:31:26 PDT Date: Mon, 13 Jun 94 16:31:26 PDT Message-Id: <9406132331.AB17919@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: sob@hsdndev.harvard.edu (Scott Bradner), Bob.Hinden@eng.sun.com, atkinson@itd.nrl.navy.mil, bound@zk3.dec.com, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com, yakov@watson.ibm.com From: Greg Minshall Subject: Re: Whats the Motivation for Variable Addresses ?? Scott, >one reason for var length addresses was just mentioned on big-i. >if one has 16 Byte addresses as the basic address and wants to >support source routing the resulting header could get quite >large. esp. if what one wanted to do in the source route >was to do cluster or provider routing which might not require >a full node address to define. Variable lengthed *addresses* != source routes. And, need to stay entirely separate. An address addresses an end node. A source route is some constraints on how to *get* to the end node. Greg From bound@zk3.dec.com Mon Jun 13 22:42:09 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id WAA06191 for ; Mon, 13 Jun 1994 22:45:59 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA19747; Mon, 13 Jun 94 19:42:17 -0700 Received: by xirtlu.zk3.dec.com; id AA28915; Mon, 13 Jun 1994 22:42:15 -0400 Message-Id: <9406140242.AA28915@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: X/Open looking at FIRP Convergence too fyi ... Date: Mon, 13 Jun 94 22:42:09 -0400 X-Mts: smtp ------- Forwarded Message Return-Path: us2rmc::petja@xopen.co.uk Received: by xirtlu.zk3.dec.com; id AA28641; Mon, 13 Jun 1994 22:02:09 -0400 Date: Mon, 13 Jun 1994 22:02:09 -0400 Message-Id: <9406140202.AA28641@xirtlu.zk3.dec.com> From: us2rmc::petja@xopen.co.uk (Petr Janecek) To: XoTGnet@xopen.co.uk Subject: (XoTGnet 4581) FYI: US Federal I-working Review Panel Report Date: Fri, 10 Jun 1994 15:43:17 +0100 To: follett@access.digex.net (Bob Follett) From: a.walker@xopen.co.uk (Andrew Walker) Subject: (a.walker 3333) US Federal Internetworking Review Panel Report Comments: (m.lambert 10532,p.janecek 8691) Bob, I have just received this note from Jack Houldsworth. It looks to me as though whoever is doing this work needs to be pointed to the X/Open XTI and MPTN specifications. Are you involved in this at all, and do you know what the process might be? Andrew >------------------------------ Start of body part 1 > >The above panel has just issued it's final report. As expected, >it recommends coexistence of OSI and TCP/IP in US GOSIP but with >strong caveats on convergence. I am particularly pleased with >the attached section on OSI-TCP/IP convergence which I couldn't >have worded better if I had written it myself. Entering the >internet 'lions den' was worthwhile after all!! Jack > >------------------------------ Start of body part 2 > > > > > > > > Part of Section 4.4 - FIRP Report > > Convergence. The inclusion of protocols from both the IPS > and OSI in a broadened GOSIP inevitably raises the issue of > interoperability between communities using different > protocols, and strategies for convergence to a single > solution. The Panel believes that the long-term resolution > lies in harmonization of the standards process, as discussed > in section 4.3. In the near and mid-term, coexistence and > interoperability are inevitable and practical, although > imperfect. Commercial routers support IP, CLNP, and > proprietary protocols, enabling coexistence of different > protocols on a shared backbone without interoperability. > The Internet carries both IPS and OSI applications, using > RFC 1006 for OSI applications over TCP/IP. X.400 to SMTP > mail gateways provide interoperability, albeit with lowest > common denominator functionality. > > There are two areas where the Panel believes immediate > attention is warranted to start to bring the existing IPS > and OSI stacks together: the network layer, and the > transport layer interface. A new internetworking protocol > is required by the Internet because of address space > limitations. The IETF has been working for some time now on > the specification of a new Internetworking layer, to > transition to from the existing IPv4. This process is based > on trying to achieve compatibility with the existing base of > deployed network and host hardware and software, the ability > to scale to very large sizes, and to add new functionality > in the areas of resource control, management and security. > The Panel believes that the convergence of both IPS and OSI > to this new internetworking layer would be a win-win > situation for all groups. A single standard recognized by > both the IETF and JTC1 would have far wider acceptance than > CLNP, and would promote the harmonization of upper layer > protocols between the groups. A single naming and > addressing scheme that is accepted worldwide is essential > for international interoperability. > > The path to convergence is for OSI and IPS applications to > coexist over a common transport and internetworking > protocol. RFC 1006 was originally created to foster a > testing atmosphere for OSI protocols (Transport and up) over > the existing Internet. RFC 1006 specifies Transport Class 0 > over a TCP socket. However, RFC 1006 has some weaknesses > (overhead and behavior problems) and there are other > different non-interoperable variations for implementing OSI > over TCP/IP. There is now a strong requirement for > standardization of hybrid solutions, such as a stack for > interoperable use of X.400 over TCP/IP. > > The Panel recommends that the IETF and JTC1 SC 6 jointly > establish convergence workshops that take advantage of the > best characteristics of both organizations, to focus on the > above and other convergence issues that may be identified. > The technical output of the workshops would be processed by > both organizations. The Government through its > representatives and members should urge both standards > organizations to collaborate on these immediate technical > areas while continuing discussions on the long-term > harmonization of the standards process. > > >------------------------------ End of body part 2 > > -------------------------------------------------------------------------- Andrew Walker, Standards Manager Tel: +44 734 508311 x2270 X/Open Company Limited Fax: +44 734 500110 Apex Plaza, Forbury Road Home: +44 564 775489 Reading, UK, RG1 1AX EMail: a.walker@xopen.co.uk -------------------------------------------------------------------------- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from inet-gw-3.pa.dec.com by us2rmc.bb.dec.com (5.65/rmc-22feb94) id AA01090; Mon, 13 Jun 94 21:58:13 -040 % Received: from xopen.xopen.co.uk by inet-gw-3.pa.dec.com (5.65/27May94) id AA17044; Mon, 13 Jun 94 18:58:26 -070 % Received: by xopen.xopen.co.uk (1.36.108.3/15.6) id AA19837; Tue, 14 Jun 94 02:52:52 +010 % Message-Id: <9406140152.AA19837@xopen.co.uk> % Received: by xopuk.xopen.co.uk (1.36.108.3/16.2) id AA01442; Tue, 14 Jun 94 02:49:08 +010 % Date: Tue, 14 Jun 94 02:49:08 +0100 % From: Petr Janecek % To: XoTGnet@xopen.co.uk % Subject: (XoTGnet 4581) FYI: US Federal I-working Review Panel Report % Sender: XoTGnet-request@xopen.co.uk % Comments: (XoTGnet 4581) ------- End of Forwarded Message From brian@dxcoms.cern.ch Tue Jun 14 08:28:18 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA07005 for ; Tue, 14 Jun 1994 02:28:58 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05292; Tue, 14 Jun 1994 08:28:19 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA06362; Tue, 14 Jun 1994 08:28:18 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406140628.AA06362@dxcoms.cern.ch> Subject: Re: Transition Questions to help define the requirements To: bound@zk3.dec.com Date: Tue, 14 Jun 1994 08:28:18 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil, Bob.Gilligan@eng.sun.com In-Reply-To: <9406131235.AA11086@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jun 13, 94 08:35:08 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3488 Jim, Good start. I've embedded some remarks below. Where is the TACIT list in all this? Brian > --------------------------------------------------------------------- > > Will end user customers require incremental solutions to move to IPng in > many cases? > YES > Should transition be separated into several independent more focused > transitions? > > - Applications Transition > - End System Transition > - Interior Routing Transition > - Exterior Routing Transition YES > > Is having the old IPv4 address space mapped to a part of the new IPng > address space a good idea? YES > > Should exisiting APIs for IPv4 should maintain binary compatibility once > IPng is turned on? YES > > Should Administration and Configuration of the Transition be defined > clearly and with details? > Yes, but can it be done? > Will supporting both IPng and IPv4 network layers on End Systems ease the > transition? See my white paper. As far as I am concerned this is the only conceivable transition. > > What are the alterations to TCP and UDP to support IPng Transition? > > What are the changes to DNS to support IPng Transition? > > What applications will be affected by IPng bigger addresses? > > What existing network tools are/can be used to manage the Transition? > > What new tools are needed to to manage the Transition? > > What are the changes to the APIs? > > Should encapsulation be used for transition (why/where)? Yes. I think this is the only truly general method of building a multiprotocol internet, and therefore essential during transition. I had some comments about that in my IPng review too. > > Should translation be used for transition (why/where)? No. See my white paper. Remember that header translation and address translation are two very different things - you need two questions here. My answer is no in both cases though. > > What parts of IPng must be deployed on the Internet if any before > transition can begin? Obviously, routing and DNS and management tools. > > What are the requirements for providers to support IPng Transition? > > Should customers be able to begin transition at the end system or > at the routing domain for IPng? > Routing, definitely. > Will IPng only systems exist that do not contain an IPv4 network layer? Not for MANY years to come. > > Should routing control parameters be used to support transition? Yes, but this may be linked to management of encapsulation routes. > > Should transition encourage a movement to IPng only routing domains? Slooooowly > > During transition what will motivate customers to move to IPng as their > backbone routing protocol to replace IPv4? Quality of service issues. > > What are the cost trade-offs for different Transition scenarios? > > What is the end user perspective on transition? See the Fleischman, Heagerty and Carpenter white papers. > > What is the routers vendor perspective on transition? > > WHat is the operators perspective on transition? > > What is the providers perspective on transition? > > Does IPng system discovery have a role to play in IPv4 to IPng > transition? > Yes. But not discovery by multicast please. > Does IPng autoconfiguration have a role to play in IPv4 to IPng > transition? Yes. But not autoconfig by multicast please. > > What are the performance requirements of transition for each system > in the network? > Everything must be faster than with IPv4. Did you need to ask? Brian From yakov@watson.ibm.com Tue Jun 14 07:42:54 1994 Return-Path: yakov@watson.ibm.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA07981 for ; Tue, 14 Jun 1994 07:44:30 -0400 From: yakov@watson.ibm.com Message-Id: <199406141144.HAA07981@picard.cmf.nrl.navy.mil> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2183; Tue, 14 Jun 94 07:44:28 EDT Date: Tue, 14 Jun 94 07:42:54 EDT To: Greg_Minshall@novell.com, sob@hsdndev.harvard.edu, Bob.Hinden@eng.sun.com, atkinson@itd.nrl.navy.mil, bound@zk3.dec.com, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com Subject: Whats the Motivation for Variable Addresses ?? Ref: Your note of Mon, 13 Jun 94 16:31:26 PDT Greg, >Variable length *addresses* != source routes. And, need to stay >entirely separate. Source route is nothing, but a sequence of addresses. Some of these addresses may be unicast addresses (they identify individual entities), some of these addresses may be anycast addresses (they identify a group of entities that form an equivalence class). A source route should allow an intermix of both (unicast and anycast). Since variable length addresses have direct implications on the efficiency of the address encoding, and since a source route is nothing, but a sequence of addresses, I would suggest us to examine the following three (orthogonal) issues: (1) should all unicast addresses be of the same length (2) should all anycast addresses be of the same length (3) if the answer to both (1) and (2) is "yes", then should the length of an anycast address be the same as the length of a unicast address. Yakov. From jallard@microsoft.com Tue Jun 14 20:39:38 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA13855 for ; Tue, 14 Jun 1994 23:44:12 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA13615; Tue, 14 Jun 94 19:45:58 -0700 Message-Id: <9406150245.AA13615@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 14 Jun 94 19:45:58 PDT X-Msmail-Message-Id: C47239A5 X-Msmail-Conversation-Id: C47239A5 X-Msmail-Fixed-Font: 0001 From: "James 'J' Allard" To: ipng@cmf.nrl.navy.mil Date: Tue, 14 Jun 94 20:39:38 TZ Subject: agenda for second retreat although the second retreat was scheduled to incorporate transition issues, the backpedlling on the sipp list on variable length, etc.. suggests that some of the road issues need to be ironed out. i personally don't think that they are orthagonal, the routing header impacts transition issues, for example, if we keep the ipv4 header, transition is a non-issue. if we adopt nsaps, it's probably not as simple. scott/allision, can we try to hash this out before the meeting so that we are better prepared? the chicago event, although useful, would have been more productive if participants had a heads up beforehand. thx _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From bound@zk3.dec.com Tue Jun 14 10:47:04 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA09099 for ; Tue, 14 Jun 1994 10:56:20 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA29001; Tue, 14 Jun 94 07:47:21 -0700 Received: by xirtlu.zk3.dec.com; id AA00618; Tue, 14 Jun 1994 10:47:10 -0400 Message-Id: <9406141447.AA00618@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: Greg_Minshall@novell.com, sob@hsdndev.harvard.edu, Bob.Hinden@eng.sun.com, atkinson@itd.nrl.navy.mil, bound@zk3.dec.com, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Tue, 14 Jun 94 07:42:54 EDT." <199406141144.HAA07981@picard.cmf.nrl.navy.mil> Date: Tue, 14 Jun 94 10:47:04 -0400 X-Mts: smtp Yakov, I am quite familiar at this point with the anycast RFC for advanced development reasons in our network kernel. Why do you propose the anycast address is different in length from a unicast address. /jim From bound@zk3.dec.com Tue Jun 14 10:55:02 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA09193 for ; Tue, 14 Jun 1994 11:04:18 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA29428; Tue, 14 Jun 94 07:55:10 -0700 Received: by xirtlu.zk3.dec.com; id AA01015; Tue, 14 Jun 1994 10:55:08 -0400 Message-Id: <9406141455.AA01015@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, Bob.Gilligan@eng.sun.com Subject: Re: Transition Questions to help define the requirements In-Reply-To: Your message of "Tue, 14 Jun 94 08:28:18 +0200." <9406140628.AA06362@dxcoms.cern.ch> Date: Tue, 14 Jun 94 10:55:02 -0400 X-Mts: smtp Brian, I have sent mail to Atul Bansal to connect with Geoff Huston on TACIT so I will let you know the response. I am not sure if we want to discuss your reply now. I will keep it for the retreat. But I do want to understand what is your issue with multicast for systems discovery in IPng????? In that bullet. thanks /jim From yakov@watson.ibm.com Tue Jun 14 11:17:06 1994 Return-Path: yakov@watson.ibm.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA09450 for ; Tue, 14 Jun 1994 11:21:13 -0400 From: yakov@watson.ibm.com Message-Id: <199406141521.LAA09450@picard.cmf.nrl.navy.mil> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5639; Tue, 14 Jun 94 11:21:07 EDT Date: Tue, 14 Jun 94 11:17:06 EDT To: bound@zk3.dec.com cc: Greg_Minshall@novell.com, sob@hsdndev.harvard.edu, Bob.Hinden@eng.sun.com, atkinson@itd.nrl.navy.mil, bound@zk3.dec.com, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com Subject: Whats the Motivation for Variable Addresses ?? Ref: Your note of Tue, 14 Jun 94 10:47:04 -0400 Jim, >Why do you propose the anycast address is different in length >from a unicast address. If you think that unicast address should be 16 bytes long, then if an anycast address is the same length as a unicast address it follows that an anycast address should be 16 bytes long. One use of an anycast address is as a "cluster" address for source route (e.g. provider selection). Now if we'll require anycast addresses to be the same length as unicast addresses, it follows that each entry in a source route has to be 16 bytes long. Don't you think this is a bit inefficient ? Yakov. From brian@dxcoms.cern.ch Tue Jun 14 17:31:21 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA09560 for ; Tue, 14 Jun 1994 11:33:13 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10179; Tue, 14 Jun 1994 17:31:23 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29829; Tue, 14 Jun 1994 17:31:21 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406141531.AA29829@dxcoms.cern.ch> Subject: Re: Transition Questions to help define the requirements To: bound@zk3.dec.com Date: Tue, 14 Jun 1994 17:31:21 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil, Bob.Gilligan@eng.sun.com In-Reply-To: <9406141455.AA01015@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jun 14, 94 10:55:02 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1467 Jim, > But I do want to understand what is your issue with multicast for > systems discovery in IPng????? In that bullet. > Repeat after me: discovery protocols based on multicast don't scale. If you are running a network with a reasonable number of hosts, let's say that a host called Snafu sends a multicast saying "any Fubar printers out there?". This packet has to be discarded by all systems set up for that multicast group. What happens in real life is that some junior programmer has failed to notice the text in the RFC about silent discards, so all the Barfu printers reply saying "I am not a Fubar printer". To do this they ARP Snafu first. In at least one case we are debugging now, Snafu then ARPs all the Barfu printers in turn for some reason. The probability that Snafu actually finds a Fubar printer is low, and everybody else suffers response time problems or worse. The names in the above have been changed to protect the guilty :-) What have we got here? A paradigm that works in good weather, but fails when challenged by sloppy programming and complex environments. This is not right. There is a known solution in an expired Internet Draft: draft-ietf-svrloc-resloc-00.txt BTW people sometimes say "you have this problem because your network is too big" (i.e. not subnetted). No. The difference is that on a big network, you notice the problem. Why should I have to buy N routers and local servers because of broken software? Brian From bound@zk3.dec.com Tue Jun 14 11:38:58 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA09689 for ; Tue, 14 Jun 1994 11:44:36 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA02434; Tue, 14 Jun 94 08:39:53 -0700 Received: by xirtlu.zk3.dec.com; id AA03405; Tue, 14 Jun 1994 11:39:06 -0400 Message-Id: <9406141539.AA03405@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: bound@zk3.dec.com, Greg_Minshall@novell.com, sob@hsdndev.harvard.edu, Bob.Hinden@eng.sun.com, atkinson@itd.nrl.navy.mil, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Tue, 14 Jun 94 11:17:06 EDT." <199406141521.LAA09450@picard.cmf.nrl.navy.mil> Date: Tue, 14 Jun 94 11:38:58 -0400 X-Mts: smtp Yakov, >One use of an anycast address is as a "cluster" address for >source route (e.g. provider selection). Now if we'll require >anycast addresses to be the same length as unicast addresses, >it follows that each entry in a source route has to be 16 bytes long. >Don't you think this is a bit inefficient ? Well this was not my view of what an anycast address was used for but rather to address my OSF/1 Advanced Cluster on the network as one example. But I see your point. This is why I really liked the SIPP ASEQ record idea. It handles this problem very well but gives me a fixed transport address (see SIPP ROAD, API, ICMP/Discovery, and Autoconfig docs). If 16bytes is fixed then the cluster address would be exracted from that address space. Or you just carry the 16bytes. The solution is in SIPP ASEQ records. Maybe you, Steve D, and Paul can come to some consensus on that. If I give you a defintiion and way to have a fixed transport ID can you and Steve come up with supporting a routing sequence based on 8 byte chunks. Why not get John Moy and Tony/Dino in the loop too and Ross too. Can't we make SIPP ASEQ records work they are a good common ground technically. /jim From yakov@watson.ibm.com Tue Jun 14 12:07:58 1994 Return-Path: yakov@watson.ibm.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA09882 for ; Tue, 14 Jun 1994 12:09:21 -0400 From: yakov@watson.ibm.com Message-Id: <199406141609.MAA09882@picard.cmf.nrl.navy.mil> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6539; Tue, 14 Jun 94 12:09:18 EDT Date: Tue, 14 Jun 94 12:07:58 EDT To: bound@zk3.dec.com cc: bound@zk3.dec.com, Greg_Minshall@novell.com, sob@hsdndev.harvard.edu, Bob.Hinden@eng.sun.com, atkinson@itd.nrl.navy.mil, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com Subject: Whats the Motivation for Variable Addresses ?? Ref: Your note of Tue, 14 Jun 94 11:38:58 -0400 >Well this was not my view of what an anycast address was used for... >But I see your point. Good. >This is why I really liked the SIPP ASEQ record idea. It handles >this problem very well but gives me a fixed transport address >(see SIPP ROAD, API, ICMCP Discovery, and Autoconfig docs). Before the retreat Deborah Estrin, Tony Li and myself wrote an IPng requirements document (draft-estrin-ipng-unified-routing-00.txt). I don't think SIPP ASEQ record idea can meet the requirements outlined in that document. >The solution is in SIPP ASEQ records. I think this is an inappropriate solution. A better solution is to put source route into the main IPng header, allow each entry in the source route to be variable length (multiple of 8 octets) so that you can intermix anycast and unicast addresses as source route elements, and provide with each source route element an indication whether it is a strict or a loose segment of the source route. Yakov. From bound@zk3.dec.com Tue Jun 14 23:03:41 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA13686 for ; Tue, 14 Jun 1994 23:06:01 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA11340; Tue, 14 Jun 94 20:03:50 -0700 Received: by xirtlu.zk3.dec.com; id AA15247; Tue, 14 Jun 1994 23:03:47 -0400 Message-Id: <9406150303.AA15247@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, Bob.Gilligan@eng.sun.com Subject: Re: Transition Questions to help define the requirements In-Reply-To: Your message of "Tue, 14 Jun 94 17:31:21 +0200." <9406141531.AA29829@dxcoms.cern.ch> Date: Tue, 14 Jun 94 23:03:41 -0400 X-Mts: smtp Brian, I see your point about Multicast. I don't agree that it cannot be solved but I was not advocating multicast (at least in my meaning of system discovery for transition). This would be an issue to discuss with the IPng working group when building system discovery. My point (and its OK if we extend it I am just a list maker at this point) was that can we use system discovery abstractly to determine things like prefixes or mapping is we need such parts for transition. I do prefer that system discovery eventually conclude at the internetwork layer as in ICMP today. /jim From bound@zk3.dec.com Tue Jun 14 23:26:27 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA13793 for ; Tue, 14 Jun 1994 23:31:45 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA12512; Tue, 14 Jun 94 20:26:36 -0700 Received: by xirtlu.zk3.dec.com; id AA15438; Tue, 14 Jun 1994 23:26:33 -0400 Message-Id: <9406150326.AA15438@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: bound@zk3.dec.com, Greg_Minshall@novell.com, sob@hsdndev.harvard.edu, Bob.Hinden@eng.sun.com, atkinson@itd.nrl.navy.mil, dkatz@cisco.com, ipng@cmf.nrl.navy.mil, kre@munnari.oz.au, tli@cisco.com Subject: Re: Whats the Motivation for Variable Addresses ?? In-Reply-To: Your message of "Tue, 14 Jun 94 12:07:58 EDT." <9406141610.AA29624@decvax.dec.com> Date: Tue, 14 Jun 94 23:26:27 -0400 X-Mts: smtp =>This is why I really liked the SIPP ASEQ record idea. It handles =>this problem very well but gives me a fixed transport address =>(see SIPP ROAD, API, ICMCP Discovery, and Autoconfig docs). >Before the retreat Deborah Estrin, Tony Li and myself wrote >an IPng requirements document (draft-estrin-ipng-unified-routing-00.txt). >I don't think SIPP ASEQ record idea can meet the requirements >outlined in that document. I am not sure it has to. Or anyother non Completed Standards in thE IETF. I think we would need to go over the arguments con in detail. >The solution is in SIPP ASEQ records. >I think this is an inappropriate solution. A better solution is to put >source route into the main IPng header, allow each entry in the source >route to be variable length (multiple of 8 octets) so that you can >intermix anycast and unicast addresses as source route elements, and >provide with each source route element an indication whether it is a >strict or a loose segment of the source route. Fine thats just an ASEQ record in the header now. Put the length out in the header, make the first 8 bytes an IAD, and I am closer to your line of beliefs about routing for IPng. /jim From bound@zk3.dec.com Tue Jun 14 23:29:31 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA13788 for ; Tue, 14 Jun 1994 23:30:58 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA12663; Tue, 14 Jun 94 20:29:39 -0700 Received: by xirtlu.zk3.dec.com; id AA15468; Tue, 14 Jun 1994 23:29:37 -0400 Message-Id: <9406150329.AA15468@xirtlu.zk3.dec.com> To: Steve Coya Cc: ipng@cmf.nrl.navy.mil Subject: Re: Participants at Retreat 2 In-Reply-To: Your message of "Tue, 14 Jun 94 15:05:55 EDT." <9406141505.aa07522@IETF.CNRI.Reston.VA.US> Date: Tue, 14 Jun 94 23:29:31 -0400 X-Mts: smtp Don't we need to invite Yakov, Tony, Dave Katz, and Bob Gilligan? /jim From bound@zk3.dec.com Wed Jun 15 00:24:06 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA14085 for ; Wed, 15 Jun 1994 00:26:13 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA15392; Tue, 14 Jun 94 21:24:17 -0700 Received: by xirtlu.zk3.dec.com; id AA16291; Wed, 15 Jun 1994 00:24:13 -0400 Message-Id: <9406150424.AA16291@xirtlu.zk3.dec.com> To: "James 'J' Allard" Cc: ipng@cmf.nrl.navy.mil Subject: Re: agenda for second retreat In-Reply-To: Your message of "Tue, 14 Jun 94 20:39:38 +0700." <9406150245.AA13615@netmail2.microsoft.com> Date: Wed, 15 Jun 94 00:24:06 -0400 X-Mts: smtp >although the second retreat was scheduled to incorporate >transition issues, the backpedlling on the sipp list on >variable length, etc.. suggests that some of the road >issues need to be ironed out. i personally don't think >that they are orthagonal, the routing header impacts transition >issues, for example, if we keep the ipv4 header, transition is >a non-issue. if we adopt nsaps, it's probably not as simple. I don't see anyone adopting NSAPs other than trying to maybe give them a way to enter the IPng address space. But I do think we need a day for transition as it is absolutely critical. I agree we cannot define the technical details but we need to at least figure out what the core requirements are at this point in time and discuss it as a Directorate with that as part of our charter. I think Steve and Paul told us they had to see what the working group wanted to do. Thats whats happening now. /jim From brian@dxcoms.cern.ch Wed Jun 15 09:28:58 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id DAA14632 for ; Wed, 15 Jun 1994 03:29:39 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22757; Wed, 15 Jun 1994 09:29:01 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22889; Wed, 15 Jun 1994 09:28:58 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406150728.AA22889@dxcoms.cern.ch> Subject: Re: Transition Questions to help define the requirements To: bound@zk3.dec.com Date: Wed, 15 Jun 1994 09:28:58 +0200 (MET DST) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, Bob.Gilligan@eng.sun.com In-Reply-To: <9406150303.AA15247@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jun 14, 94 11:03:41 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 690 We agree Brian >--------- Text sent by bound@zk3.dec.com follows: > > Brian, > > I see your point about Multicast. I don't agree that it cannot be > solved but I was not advocating multicast (at least in my meaning of > system discovery for transition). This would be an issue to discuss > with the IPng working group when building system discovery. > > My point (and its OK if we extend it I am just a list maker at this > point) was that can we use system discovery abstractly to determine > things like prefixes or mapping is we need such parts for transition. > > I do prefer that system discovery eventually conclude at the > internetwork layer as in ICMP today. > > /jim > From sob@hsdndev.harvard.edu Sun Jun 19 20:58:02 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA13644 for ; Sun, 19 Jun 1994 20:58:07 -0400 Date: Sun, 19 Jun 94 20:58:02 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406200058.AA08681@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: back (almost) Well, we are finally back from the travels. I got back from a week in berlin & a week in Prague friday night and Allison gets back from a week in Prague tonight. We will get cought up asap and get meeting related stuff out as soon as we can. Scott From brian@dxcoms.cern.ch Mon Jun 20 11:44:23 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id FAA15096 for ; Mon, 20 Jun 1994 05:44:58 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16588; Mon, 20 Jun 1994 11:44:24 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA08428; Mon, 20 Jun 1994 11:44:24 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406200944.AA08428@dxcoms.cern.ch> Subject: this week's CIDR progress: bad news (fwd) To: ipng@cmf.nrl.navy.mil Date: Mon, 20 Jun 1994 11:44:23 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2458 >--------- Text sent by Jean-Michel Jouanigot follows: >From jimi Mon Jun 20 10:28:50 1994 X-Delivered: at request of brian on dxcoms.cern.ch From: jimi (Jean-Michel Jouanigot) Message-Id: <9406200704.AA01016@dxcoms.cern.ch> Subject: this week's CIDR progress: bad news To: csen@crnvma.cern.ch, brian@dxcern.cern.ch, fluckiger@axcrnc.cern.ch Date: Mon, 20 Jun 1994 09:04:13 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1913 Everybody knew it will not last very long, unfortunately! -- Jean-Michel >----- Text sent by Jessica Yu follows ------- >From list-admin@merit.edu Fri Jun 17 21:16:42 1994 X-Delivered: at request of jimi on dxcoms.cern.ch Message-Id: <199406171847.OAA25161@merit.edu> To: bgpd@merit.edu, regional-techs@merit.edu Cc: jyy@merit.edu Subject: this week's CIDR progress Date: Fri, 17 Jun 1994 14:47:25 -0400 From: Jessica Yu Hi, Folks: The high growth rate of routing table is comming back. We gained 134 routes last week and that is all time high since CIDR got widely deployed dated back in Apr. It is time to do SOMETHING at your AS to bring the number down. If you have not run BGP4 yet, run BGP4 or delegate your CIDR capable neibhbor to do proxy aggregate. If you have already run BGP4 but not doing aggregate, advertise aggregate and withdrawn more specific routes. Do something now and let's see the number next week. --jessica -------------------- This past week's (between 6/10 12:00(edt) - 6/17 12:00(edt)) CIDR progress from AS690's point view: Route table growth: 134 routes (ALARM!!! ) Route withdrawn: 36 routes The following ASs and/or ASs behind them have withdrawn more specific routes during the period: 97 JvNCnet 17 701 AlterNet 9 1800 ICM-Atlantic 5 3577 PREPnet-WEST 1 293 ESNet 1 2551 NETCOM 1 1957 ANSCIX-AS 1 1329 ANS Greensboro 1 New challenges: There are 1081 routes co-existing with its aggregate in the routing table currently, that is they can be withdrawn as we speak. ASs who advertise these routes PLEASE withdrawn them. A list of withdrawable routes will be sent to the contact individual ASs. Thanks! --jessica -- Jean-Michel From bound@zk3.dec.com Mon Jun 20 15:55:37 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA01144 for ; Mon, 20 Jun 1994 16:02:58 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA13206; Mon, 20 Jun 94 12:55:47 -0700 Received: by xirtlu.zk3.dec.com; id AA08104; Mon, 20 Jun 1994 15:55:44 -0400 Message-Id: <9406201955.AA08104@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: bound@zk3.dec.com Subject: HELP - Convergence in IPng Date: Mon, 20 Jun 94 15:55:37 -0400 X-Mts: smtp Scott and Allison, Whats our party line here. I am soon (after Toronto) being asked to go out into the U.S., Asia, and Europe to talk about IPng from a Digital perspective for our IP, OSI, IPX, et al customers. Most of these will be from a DECUS focus, but some will be on site. These are being scheduled for Sept-December. They did not want marketing people and wanted the tech leaders to do this. It seems my name is being used in vain on this subject, and I thought we were being so quiet. So far convergence is not in the requirments so this is a vendor only thing right now. I don't mind saying that but is that what we are going to say as a Directorate? But many are seeing the discussions on Big-I and SIPP and think now we are doing convergence. This is a heads up. Are we putting convergence back into the IPng requirements? For the U.S. base FIRP has recommended it strongly and that RFC1006 is just not enough. Did you get this kind of input at INET94? /jim From brian@dxcoms.cern.ch Tue Jun 21 08:26:35 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA04665 for ; Tue, 21 Jun 1994 02:27:11 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04011; Tue, 21 Jun 1994 08:26:36 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05233; Tue, 21 Jun 1994 08:26:36 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406210626.AA05233@dxcoms.cern.ch> Subject: Re: HELP - Convergence in IPng To: bound@zk3.dec.com Date: Tue, 21 Jun 1994 08:26:35 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <9406201955.AA08104@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jun 20, 94 03:55:37 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 524 IMHO, convergence is like ATM compatibility and motherhood. No senior manager could ever deny that it is a GOOD THING. The question is, after the OSI experience, is it technically plausible? As you may have noticed :-) I have been debating address space requirements for convergence with Mr Simpson. You will gather that I still hope that some kind of convergence is plausible. If so, it is clearly desirable, but convergence with real-world protocols is more important than convergence with a virtual CLNP world. Brian From brian@dxcoms.cern.ch Tue Jun 21 17:49:53 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA07387 for ; Tue, 21 Jun 1994 11:50:27 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA25125; Tue, 21 Jun 1994 17:49:53 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20447; Tue, 21 Jun 1994 17:49:53 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406211549.AA20447@dxcoms.cern.ch> Subject: data point To: ipng@cmf.nrl.navy.mil Date: Tue, 21 Jun 1994 17:49:53 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 385 IPng folks, Without wanting to line up with Mr Simpson, I had better pass this on. John Lumley of HP Labs (Bristol) today gave me as his opinion that 3 or 4 levels of hierarchy and 24 address bits are enough for HP's corporate network (100k staff, 1M nodes foreseen). This is not a corporate position of course. Note that HP is an IP-only shop except for a few IPX islands. Brian From mankin@cmf.nrl.navy.mil Tue Jun 21 13:19:09 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id NAA09204 for ; Tue, 21 Jun 1994 13:19:13 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id NAA15842; Tue, 21 Jun 1994 13:19:09 -0400 Date: Tue, 21 Jun 1994 13:19:09 -0400 From: Allison J Mankin Message-Id: <199406211719.NAA15842@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: Logistics of Workshop #2 Cc: hinden@eng.sun.com Hi, folks, Since a primary focus of this Directorate meeting is the Transition, strategies and review of proposals, we are inviting Bob Hinden, Erik Nordmark and Bob Gilligan to join us. Since it was very difficult for Bob H. and for Steve Deering to travel East, Bob and Sun are going to host our meeting using their analog video link from east-west. Bob has arranged for us to use Picturetel facilities at Sun in the Bay Area and Sun in Chelmsford MA. He will be sending out directions shortly for both facilities. Those on the East coast who are staying in the Sheraton Commander, Scott and I will drive you to Chelmsford. Others can meet us in Cambridge in the morning if they like and grab the ride too, if they like, or just meet us there. The facility will be open to us at about 1 PM EDT on Sunday and at noon EDT on Monday. On Sunday we will run as late as we can, on Monday we will end fairly early to make sure we get people to their flights at Logan. Look out for Bob's message. Also, please send Steve Coya your RSVP and let him compile a list for Bob Hinden of the attendees on each coast. Thanks. Scott and Allison From rcallon@pobox.wellfleet.com Tue Jun 21 13:25:49 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA09417; Tue, 21 Jun 1994 13:30:26 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA07731; Tue, 21 Jun 94 13:28:35 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA13847; Tue, 21 Jun 94 13:25:49 EDT Date: Tue, 21 Jun 94 13:25:49 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9406211725.AA13847@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil Subject: Re: Logistics of Workshop #2 Cc: hinden@eng.sun.com Alison; Are we still planning on discussing transition on Sunday, and addressing on Monday? Or are we planning on discussing transition both days? Ross From smb@research.att.com Tue Jun 21 13:27:34 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA09414; Tue, 21 Jun 1994 13:30:02 -0400 From: smb@research.att.com Message-Id: <199406211730.NAA09414@picard.cmf.nrl.navy.mil> Received: by gryphon; Tue Jun 21 13:27:34 EDT 1994 To: Allison J Mankin cc: ipng@cmf.nrl.navy.mil, hinden@eng.sun.com Subject: Re: Logistics of Workshop #2 Date: Tue, 21 Jun 94 13:27:34 EDT Will there be a speakerphone, too? From lixia@parc.xerox.com Tue Jun 21 11:33:21 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA11123; Tue, 21 Jun 1994 14:34:32 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14548(5)>; Tue, 21 Jun 1994 11:33:41 PDT Received: by redwing.parc.xerox.com id <57153>; Tue, 21 Jun 1994 11:33:35 -0700 Date: Tue, 21 Jun 1994 11:33:21 PDT Sender: Lixia Zhang From: Lixia Zhang To: Allison J Mankin Cc: ipng@cmf.nrl.navy.mil, hinden@eng.sun.com Subject: Re: Logistics of Workshop #2 In-Reply-To: Your message of Tue, 21 Jun 1994 10:19:09 -0700 Message-ID: > The facility will be open to us at about 1 PM EDT on Sunday and at > noon EDT on Monday. On Sunday we will run as late as we can, on > Monday we will end fairly early to make sure we get people to their > flights at Logan. Does this mean that we wont start the meeting until noon each day? How early is the early ending on Monday? (I'm currently booked on a Tue morning flight, based on your earlier statment that "we'll have long meetings both days"). If you end by 5pm, then I'll change my flight. But if we only meet from noon to 5pm on Monday (the only day all people will show up), that's not much time. Lixia From Bob.Hinden@Eng.Sun.COM Tue Jun 21 11:43:05 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA11451; Tue, 21 Jun 1994 14:49:24 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09061; Tue, 21 Jun 94 11:43:12 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA00775; Tue, 21 Jun 94 11:45:15 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA06661; Tue, 21 Jun 1994 11:43:05 -0700 Date: Tue, 21 Jun 1994 11:43:05 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406211843.AA06661@jurassic.Eng.Sun.COM> To: Lixia Zhang Cc: Allison J Mankin , ipng@cmf.nrl.navy.mil, hinden@Eng.Sun.COM In-Reply-To: Subject: Re: Logistics of Workshop #2 Lixia, I think the intent is to start earlier on Monday. Bob From Greg_Minshall@Novell.COM Tue Jun 21 12:30:14 1994 Replied: Tue, 21 Jun 94 15:50:16 -0400 Replied: "Greg Minshall , lixia@parc.xerox.com " Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA12444; Tue, 21 Jun 1994 15:34:22 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11838; Tue, 21 Jun 94 13:33:31 MDT Received: from [130.57.64.149] by WC.Novell.COM (4.1/SMI-4.1) id AA10984; Tue, 21 Jun 94 12:30:15 PDT Date: Tue, 21 Jun 94 12:30:14 PDT Message-Id: <9406211930.AA10984@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Allison J Mankin From: Greg Minshall Subject: Re: Logistics of Workshop #2 Cc: hinden@eng.sun.com, ipng@cmf.nrl.navy.mil Allison, I think we clearly need full days. I think starting at noon on Sunday is unfortunate. (I think staying late Sunday evening is unfortunate, but only 'cause i've already made child care plans. Silly me...) I think starting at 1 pm on Monday is unfortunate. I don't think that *Steve D.* is really all *that* interested in transition plans (but, then, he's in the Czech mountains, and in no position to contradict me). I can understand Bob (hi, Bob) being interested in transition plans. However, Erik and Bob G. will be there representing (to some extent) Bob's philosophy, etc. (And, maybe Bob could be prevailed upon to attend in person? - but i don't have any clue about that.) So, i'd suggest 9-5 or so on Sunday, sans TV. 9-whatever on Monday, again sans TV. With a speaker phone. Located in Cambridge, if in fact there are lots of people from out of town staying there? Greg From bound@zk3.dec.com Wed Jun 22 07:56:02 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA28030; Wed, 22 Jun 1994 08:01:27 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA00789; Wed, 22 Jun 94 04:56:20 -0700 Received: by xirtlu.zk3.dec.com; id AA16258; Wed, 22 Jun 1994 07:56:08 -0400 Message-Id: <9406221156.AA16258@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: bound@zk3.dec.com, Greg_Minshall@novell.com, mankin@cmf.nrl.navy.mil, hinden@eng.sun.com, ipng@cmf.nrl.navy.mil Subject: Re: Logistics of Workshop #2 In-Reply-To: Your message of "Wed, 22 Jun 94 08:11:02 +0200." <9406220611.AA02656@dxcoms.cern.ch> Date: Wed, 22 Jun 94 07:56:02 -0400 X-Mts: smtp >Well, I associate the Westford Regency so strongly with DECnet >non-disclosure meetings that I think I could only talk about >NSAPAs there :-) Next time it will IPng I guess. >Seriously - I prefer not to change hotels because (a) I plan to >cancel my rental car and use the T (b) I am in a panic between now >and flight time on Saturday, and everything is set up already. Good point. Folks its Wednesday. Sunday is 4 days away. Whats the final story. /jim From bound@zk3.dec.com Wed Jun 22 08:37:59 1994 Return-Path: bound@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com [16.140.0.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA28703 for ; Wed, 22 Jun 1994 08:38:17 -0400 From: bound@zk3.dec.com Received: from pyrus.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA05972; Wed, 22 Jun 1994 08:38:08 -0400 Received: from localhost by abyss.zk3.dec.com; (5.65/1.1.8.2/25May94-8.2MPM) id AA15239; Wed, 22 Jun 1994 08:38:06 -0400 Message-Id: <9406221238.AA15239@abyss.zk3.dec.com> To: ipng@cmf.nrl.navy.mil, hinden@eng.sun.com Subject: Transition Discussion Posting #2 Date: Wed, 22 Jun 94 08:37:59 -0400 X-Mts: smtp I sent this about a week ago. At some prodding it was suggested I send it again as discussion point for Transition. /jim Return-Path: ipng-request@cmf.nrl.navy.mil Received: from decvax.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA02617; Mon, 13 Jun 1994 08:46:29 -0400 Received: from picard.cmf.nrl.navy.mil by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA26213; Mon, 13 Jun 1994 08:46:26 -0400 Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA29619 for ; Mon, 13 Jun 1994 08:41:19 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA25925; Mon, 13 Jun 94 05:35:29 -0700 Received: by xirtlu.zk3.dec.com; id AA11086; Mon, 13 Jun 1994 08:35:14 -0400 Message-Id: <9406131235.AA11086@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil, Bob.Gilligan@eng.sun.com Subject: Transition Questions to help define the requirements Date: Mon, 13 Jun 94 08:35:08 -0400 X-Mts: smtp These questions can help us understand what the issues are for transitiion. Some could become requirements other will be abstractions to define requirements. If folks start sending input I will keep it in a folder and try to coalesce it before the retreat. /jim --------------------------------------------------------------------- Will end user customers require incremental solutions to move to IPng in many cases? Should transition be separated into several independent more focused transitions? - Applications Transition - End System Transition - Interior Routing Transition - Exterior Routing Transition Is having the old IPv4 address space mapped to a part of the new IPng address space a good idea? Should exisiting APIs for IPv4 should maintain binary compatibility once IPng is turned on? Should Administration and Configuration of the Transition be defined clearly and with details? Will supporting both IPng and IPv4 network layers on End Systems ease the transition? What are the alterations to TCP and UDP to support IPng Transition? What are the changes to DNS to support IPng Transition? What applications will be affected by IPng bigger addresses? What existing network tools are/can be used to manage the Transition? What new tools are needed to to manage the Transition? What are the changes to the APIs? Should encapsulation be used for transition (why/where)? Should translation be used for transition (why/where)? What parts of IPng must be deployed on the Internet if any before transition can begin? What are the requirements for providers to support IPng Transition? Should customers be able to begin transition at the end system or at the routing domain for IPng? Will IPng only systems exist that do not contain an IPv4 network layer? Should routing control parameters be used to support transition? Should transition encourage a movement to IPng only routing domains? During transition what will motivate customers to move to IPng as their backbone routing protocol to replace IPv4? What are the cost trade-offs for different Transition scenarios? What is the end user perspective on transition? What is the routers vendor perspective on transition? WHat is the operators perspective on transition? What is the providers perspective on transition? Does IPng system discovery have a role to play in IPv4 to IPng transition? Does IPng autoconfiguration have a role to play in IPv4 to IPng transition? What are the performance requirements of transition for each system in the network? /jim From mankin@radegond.cmf.nrl.navy.mil Wed Jun 22 14:12:33 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id OAA06459 for ; Wed, 22 Jun 1994 14:12:36 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id OAA17974; Wed, 22 Jun 1994 14:12:35 -0400 Message-Id: <199406221812.OAA17974@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: sipp@sunroof2.eng.sun.com cc: ipng@radegond.cmf.nrl.navy.mil Subject: IPNG ADs' Request to SIPP WG Date: Wed, 22 Jun 94 14:12:33 -0400 From: Allison J Mankin Picking up on something that Noel mentioned in a posting with the last day or two (we'd be superhuman if we could find it right now among all of the big-internet and sipp mail), we would like to request that the SIPP working group discuss and try and reach consensus on a particular issue. One thing that seems to have been missing in the recent extensive discussions about address size options in SIPP is a understanding of whether the transport level 'name' should be the same as the internetwork level 'name', as they are with the current IPv4 "address", or be different in some way. Different people seem to often be making different assumptions about the answer to this question in recent notes, with the result that a lot of the discussion was not as productive as it could have been, due to inconsistent terminology. If it is possible to reach consensus on this issue, it will almost certainly make it easier to reach consensus on some of the other open issues regarding "addresses". Note that it is not necessary to assume that the names in question are either fixed or variable length. Obviously, whether you have one or two is related to the details of what each would look like, but it should be possible to consider this without getting diverted by the contentious issue of fixed/variable. Please address the following questions: 1/ are the transport and internetwork level names the same thing? 2/ if not, are they totally different, or is the transport level name part of the internetwork level name? Scott & Allison From craig@aland.bbn.com Wed Jun 22 11:35:21 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA06943 for ; Wed, 22 Jun 1994 14:38:18 -0400 Received: from port17.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA26531 for mankin@cmf.nrl.navy.mil; Wed, 22 Jun 94 14:37:48 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id LAA00259; Wed, 22 Jun 1994 11:35:23 -0700 Message-Id: <199406221835.LAA00259@aland.bbn.com> To: Allison J Mankin Cc: sipp@sunroof2.eng.sun.com, ipng@radegond.cmf.nrl.navy.mil Subject: Re: IPNG ADs' Request to SIPP WG In-Reply-To: Your message of Wed, 22 Jun 94 14:12:33 -0400. <199406221812.OAA17974@radegond.cmf.nrl.navy.mil> From: Craig Partridge Date: Wed, 22 Jun 94 11:35:21 -0700 Sender: craig@aland.bbn.com Scott and Allison, Your query caused my wires to fuse. (I will confess to having missed Noel's note). I suspect a change in terminology is in progress... If I'd been asked a few months ago, I would have said a 'transport name' is the thing that unique identifies a transport layer connection, which for TCP and UDP are: My suspicion from your note is that your only talking about what the last two items are (i.e., are they the thing that IPng uses in forwarding or something else like a unicast or multicast EID). Could you clarify this for me? Thanks! Craig From dcrocker@mordor.stanford.edu Wed Jun 22 12:45:14 1994 Return-Path: dcrocker@mordor.stanford.edu Received: from Mordor.Stanford.EDU (Mordor.Stanford.EDU [36.53.0.155]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id PAA08370; Wed, 22 Jun 1994 15:45:16 -0400 Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id MAA04117; Wed, 22 Jun 1994 12:45:07 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Jun 1994 12:45:14 -0700 To: Allison J Mankin From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPNG ADs' Request to SIPP WG Cc: sipp@sunroof2.Eng.Sun.COM, ipng@radegond.cmf.nrl.navy.mil Allison & Scott, At 11:12 AM 6/22/94, Allison J Mankin wrote: >whether the transport level 'name' should be the same as the internetwork >level 'name', as they are with the current IPv4 "address", or be different >in some way. I'm honestly sorry for what I'm about to type, since this realm of discussion seems to lead to much verbiage and little comprehension... but I don't really know what you mean about an IPv4 'transport-level name'. I know of a connection id, comprising IP addresses and port numbers, but otherwise can't guess what you are referring to. Please clarify in terms of IPv4 and TCP. Thanks. Dave +1 408 246 8253 (fax: +1 408 249 6205) From sob@hsdndev.harvard.edu Wed Jun 22 17:03:41 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA10155 for ; Wed, 22 Jun 1994 17:03:58 -0400 Date: Wed, 22 Jun 94 17:03:41 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406222103.AA13282@hsdndev.harvard.edu> To: craig@aland.bbn.com, mankin@cmf.nrl.navy.mil Subject: Re: IPNG ADs' Request to SIPP WG Cc: ipng@radegond.cmf.nrl.navy.mil, sipp@sunroof2.Eng.Sun.COM Craig, You are right, sorry for the inclarity Scott From sob@hsdndev.harvard.edu Wed Jun 22 17:03:41 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA10152 for ; Wed, 22 Jun 1994 17:03:56 -0400 Date: Wed, 22 Jun 94 17:03:41 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406222103.AA13282@hsdndev.harvard.edu> To: craig@aland.bbn.com, mankin@cmf.nrl.navy.mil Subject: Re: IPNG ADs' Request to SIPP WG Cc: ipng@radegond.cmf.nrl.navy.mil, sipp@sunroof2.Eng.Sun.COM Craig, You are right, sorry for the inclarity Scott From Bob.Hinden@Eng.Sun.COM Wed Jun 22 14:16:40 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA10473 for ; Wed, 22 Jun 1994 17:19:21 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09683; Wed, 22 Jun 94 14:18:43 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA22271; Wed, 22 Jun 94 14:19:06 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA22058; Wed, 22 Jun 1994 14:16:40 -0700 Date: Wed, 22 Jun 1994 14:16:40 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406222116.AA22058@jurassic.Eng.Sun.COM> To: Allison J Mankin , sipp@sunroof2.Eng.Sun.COM, ipng@radegond.cmf.nrl.navy.mil In-Reply-To: Subject: Re: IPNG ADs' Request to SIPP WG Allison needs to clarify, but I think the question is whether the transport protocol uses the whole address as part of its connection identification (like is done with IPv4) or some subset of the address. In the case of 128bit SIPP addresses the question would be: Can the transport connection identification be done with only a subset of these 128bits or should it be done with the whole 128bits. If this is the question, then my opinion is that the transport protocol should continue to use the whole address. I have a number of problems with separating the locator part of the address from the identifier part when doing the connection identification. Note that I am not saying that an identifier (e.g. IEEE 802 MAC address) should not be in the address. An identifier in the address is very useful for auto configuration and renumbering. The problems I see with separation of location from identification include: 1) Like loose source routing, separation of location from identification means that the packet must be authenticated. Otherwise it is trivial to spoof, subvert connections, and carryout other similar attacks. Every datagram will need to be authenticated. 2) The most common kind of identifier, IEEE 802 MAC address, are not globally unique enough to serve as identifiers. A new identifier space will have to be created, managed, installed on machines, etc. It is not clear that we will be better keeping these identifiers unique than IEEE has done. 3) The problems that separate identifiers are purported to solve all have other solutions. The details of these solutions have not been worked out. 4) We don't understand many of the other ramifications of using ID's separate from locators. To me this is a research problem. This is far from a solved problem today. I believe that it is very useful concept to separate location and identification when "thinking" about transport and routing issues, but do not think that it is a good implementation choice. Bob From bound@zk3.dec.com Thu Jun 23 01:32:13 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA18760 for ; Thu, 23 Jun 1994 01:36:17 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA11998; Wed, 22 Jun 94 22:32:21 -0700 Received: by xirtlu.zk3.dec.com; id AA03583; Thu, 23 Jun 1994 01:32:19 -0400 Message-Id: <9406230532.AA03583@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: sipp@sunroof2.eng.sun.com, ipng@radegond.cmf.nrl.navy.mil Subject: Re: IPNG ADs' Request to SIPP WG In-Reply-To: Your message of "Wed, 22 Jun 94 14:12:33 EDT." <199406221812.OAA17974@radegond.cmf.nrl.navy.mil> Date: Thu, 23 Jun 94 01:32:13 -0400 X-Mts: smtp The name should only identify the transport src or dst address. We might need other names in the future but I can't parse this for IPng right now and I don't think anyone else can. I have to agree with Bob Hinden that to implement EIDs and Locators in IPng would require extensive work. If we want to move quickly with IPng then doing this will slow the processes down as we have at least nine more months of analysis on EIDs/Locators to get it implementable IMHO. But )--> What is a name? A name to me is an identifier. I think right now all we can do for IPng and get implemented is identify a transport address as in IPv4 today. That means all 128bits. If its fixed and not variable I can at least live with that. Assuming we have consensus that 128bits is enough to avoid another IPng transition for 30-40 years. But what we need to contemplate is can we separate within the identifier in some manner, that which represents information to route a packet across the Internet, from that which is only needed for local traffic and autoconfiguration as examples. This becomes a real issue for a source route. 16bytes for each entry in a source route is quite extensive I think. If we can separate these functions it can reduce the tests and masking operations for local or routed traffic. I believe it will also help with transition of IPv4 to IPng, as that gets defined in IPng, where the transition software can use the routing information to construct packets and make encapsulation or translation decisions as two examples (not that this is a good transition approach one way or the other for this discussion OK). In addition if NIMROD can come out of research into implementation mode at some point in time (which I am going to spend personal cycles on to assist where I can) then I don't want to see us have to have another transition or version number change because EIDs and Locators in fact are the superior approach to inter-networking. Thinking about this now is a prudent engineering exercise is my input to you. But trying to define multiple names could throw us into a tail spin and slow down consensus to get IPng specified in the IETF, even though theoretically multiple names to identify different parts of a network path is very possible. I also think we need to define the Multihome case in IPng clearly. /jim From bound@zk3.dec.com Thu Jun 23 01:32:13 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA18757 for ; Thu, 23 Jun 1994 01:36:12 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA11998; Wed, 22 Jun 94 22:32:21 -0700 Received: by xirtlu.zk3.dec.com; id AA03583; Thu, 23 Jun 1994 01:32:19 -0400 Message-Id: <9406230532.AA03583@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: sipp@sunroof2.eng.sun.com, ipng@radegond.cmf.nrl.navy.mil Subject: Re: IPNG ADs' Request to SIPP WG In-Reply-To: Your message of "Wed, 22 Jun 94 14:12:33 EDT." <199406221812.OAA17974@radegond.cmf.nrl.navy.mil> Date: Thu, 23 Jun 94 01:32:13 -0400 X-Mts: smtp The name should only identify the transport src or dst address. We might need other names in the future but I can't parse this for IPng right now and I don't think anyone else can. I have to agree with Bob Hinden that to implement EIDs and Locators in IPng would require extensive work. If we want to move quickly with IPng then doing this will slow the processes down as we have at least nine more months of analysis on EIDs/Locators to get it implementable IMHO. But )--> What is a name? A name to me is an identifier. I think right now all we can do for IPng and get implemented is identify a transport address as in IPv4 today. That means all 128bits. If its fixed and not variable I can at least live with that. Assuming we have consensus that 128bits is enough to avoid another IPng transition for 30-40 years. But what we need to contemplate is can we separate within the identifier in some manner, that which represents information to route a packet across the Internet, from that which is only needed for local traffic and autoconfiguration as examples. This becomes a real issue for a source route. 16bytes for each entry in a source route is quite extensive I think. If we can separate these functions it can reduce the tests and masking operations for local or routed traffic. I believe it will also help with transition of IPv4 to IPng, as that gets defined in IPng, where the transition software can use the routing information to construct packets and make encapsulation or translation decisions as two examples (not that this is a good transition approach one way or the other for this discussion OK). In addition if NIMROD can come out of research into implementation mode at some point in time (which I am going to spend personal cycles on to assist where I can) then I don't want to see us have to have another transition or version number change because EIDs and Locators in fact are the superior approach to inter-networking. Thinking about this now is a prudent engineering exercise is my input to you. But trying to define multiple names could throw us into a tail spin and slow down consensus to get IPng specified in the IETF, even though theoretically multiple names to identify different parts of a network path is very possible. I also think we need to define the Multihome case in IPng clearly. /jim From huitema@mitsou.inria.fr Thu Jun 23 10:24:52 1994 Return-Path: huitema@mitsou.inria.fr Received: from mitsou.inria.fr (mitsou.inria.fr [138.96.24.84]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA21308 for ; Thu, 23 Jun 1994 04:27:05 -0400 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA11335; Thu, 23 Jun 1994 10:24:53 +0200 Message-Id: <199406230824.AA11335@mitsou.inria.fr> To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: ipng@radegond.cmf.nrl.navy.mil, sipp@sunroof2.eng.sun.com Subject: Re: IPNG ADs' Request to SIPP WG In-Reply-To: Your message of "Thu, 23 Jun 1994 10:44:35 +0200." <9406230144.AA10249@cactus.slab.ntt.jp> Date: Thu, 23 Jun 1994 10:24:52 +0200 From: Christian Huitema => When we proposed the 128-bit address, Steve and I both assumed => that the full address also served as transport identification, => that is, same as current IP. => => PF I agree completely here. What about paraphrazing Jon's statement: "be liberal with what you research, conservative with what you standardize". We don't want to chase two birds with one stone. We have to follow the (proven) IPv4 strategy when it comes to TCP over SIPP, i.e. use the whole SIPP address. Then, we can do research. There are many avenues there, but I am sure that the solution has to involve authentication. Something like TCP over authentication over SIPP. In that case, one can rely on the authentication protocol to provide an "authentication context" and identify the TCP context by a combination of authentication context and ports, independently of the Internet addresses. As I said, this is research! I would love to see prototypes; in the mean time, just play safe, use the whole SIPP address. Christian Huitema PS. Authentication protocols will use names, most likely domain names, perhaps X.509 names. IEEE addresses or binary numbers are not relevant here. From J.Crowcroft@cs.ucl.ac.uk Thu Jun 23 09:26:51 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA21330 for ; Thu, 23 Jun 1994 04:27:49 -0400 Message-Id: <199406230827.EAA21330@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Jun 1994 09:26:52 +0100 To: Allison J Mankin , sipp@sunroof2.Eng.Sun.COM, ipng@radegond.cmf.nrl.navy.mil Subject: Re: IPNG ADs' Request to SIPP WG In-reply-to: Your message of "Wed, 22 Jun 94 12:45:14 PDT." Date: Thu, 23 Jun 94 09:26:51 +0100 From: Jon Crowcroft >At 11:12 AM 6/22/94, Allison J Mankin wrote: >>whether the transport level 'name' should be the same as the internetwork >>level 'name', as they are with the current IPv4 "address", or be different >>in some way. >but I don't really know what you mean about an IPv4 'transport-level name'. >I know of a connection id, comprising IP addresses and port numbers, but >otherwise can't guess what you are referring to. Please clarify in terms >of IPv4 and TCP. transport level name = 1/2 of the 'socket' or connection lookup key, as craig said, lookup of TCP/IPv4 PCB is src port, src IP, dst port, dst IP In an IPng, I would expect 2 possible positions src port+whole 'address', dst port + whole 'address' where address = EID+Locator or just src port + src EID, dst port + dst EID if you trust the net a bit:-) 1/2 of one of theses thingies is simply what you put in the listen() parameters, or the connect() parameters jon From J.Crowcroft@cs.ucl.ac.uk Thu Jun 23 09:26:51 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA21335 for ; Thu, 23 Jun 1994 04:28:05 -0400 Message-Id: <199406230828.EAA21335@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Jun 1994 09:26:52 +0100 To: Allison J Mankin , sipp@sunroof2.Eng.Sun.COM, ipng@radegond.cmf.nrl.navy.mil Subject: Re: IPNG ADs' Request to SIPP WG In-reply-to: Your message of "Wed, 22 Jun 94 12:45:14 PDT." Date: Thu, 23 Jun 94 09:26:51 +0100 From: Jon Crowcroft >At 11:12 AM 6/22/94, Allison J Mankin wrote: >>whether the transport level 'name' should be the same as the internetwork >>level 'name', as they are with the current IPv4 "address", or be different >>in some way. >but I don't really know what you mean about an IPv4 'transport-level name'. >I know of a connection id, comprising IP addresses and port numbers, but >otherwise can't guess what you are referring to. Please clarify in terms >of IPv4 and TCP. transport level name = 1/2 of the 'socket' or connection lookup key, as craig said, lookup of TCP/IPv4 PCB is src port, src IP, dst port, dst IP In an IPng, I would expect 2 possible positions src port+whole 'address', dst port + whole 'address' where address = EID+Locator or just src port + src EID, dst port + dst EID if you trust the net a bit:-) 1/2 of one of theses thingies is simply what you put in the listen() parameters, or the connect() parameters jon From francis@cactus.slab.ntt.jp Thu Jun 23 10:44:35 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp ([192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA15085; Wed, 22 Jun 1994 21:44:51 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Thu, 23 Jun 1994 10:44:36 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id KAA17780; Thu, 23 Jun 1994 10:44:35 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA10249; Thu, 23 Jun 94 10:44:35 JST Date: Thu, 23 Jun 94 10:44:35 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406230144.AA10249@cactus.slab.ntt.jp> To: Bob.Hinden@Eng.Sun.COM, ipng@radegond.cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil, sipp@sunroof2.Eng.Sun.COM Subject: Re: IPNG ADs' Request to SIPP WG When we proposed the 128-bit address, Steve and I both assumed that the full address also served as transport identification, that is, same as current IP. PF From jallard@microsoft.com Thu Jun 23 19:11:25 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id WAA03619 for ; Thu, 23 Jun 1994 22:16:44 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA01116; Thu, 23 Jun 94 18:18:35 -0700 Message-Id: <9406240118.AA01116@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 23 Jun 94 18:18:35 PDT X-Msmail-Message-Id: C017D9EE X-Msmail-Conversation-Id: C017D9EE From: "James 'J' Allard" To: ipng-request@cmf.nrl.navy.mil Date: Thu, 23 Jun 94 19:11:25 TZ Subject: RE: IPNG Retreat part deux i will be there _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From jallard@microsoft.com Thu Jun 23 19:11:42 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id WAA03620 for ; Thu, 23 Jun 1994 22:16:44 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA01119; Thu, 23 Jun 94 18:18:36 -0700 Message-Id: <9406240118.AA01119@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 23 Jun 94 18:18:35 PDT X-Msmail-Message-Id: 3CF56AB4 X-Msmail-Conversation-Id: 3CF56AB4 From: "James 'J' Allard" To: ipng-request@cmf.nrl.navy.mil Date: Thu, 23 Jun 94 19:11:42 TZ Subject: RE: IPNG Retreat part deux i will be at the charles hotel _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From brian@dxcoms.cern.ch Thu Jun 23 15:17:18 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA25787 for ; Thu, 23 Jun 1994 09:17:53 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13482; Thu, 23 Jun 1994 15:17:18 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA12597; Thu, 23 Jun 1994 15:17:18 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406231317.AA12597@dxcoms.cern.ch> Subject: Amoco wants... To: ipng@cmf.nrl.navy.mil Date: Thu, 23 Jun 1994 15:17:18 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1893 Directorate, I happened to meet some Amoco people this week and used this contact to ask how many address bytes they would like. Interestingly the answer is the same as HP. In neither case are the responses from people who monitor the IETF discussions. Pls don't broadcast this quote or the HP quote since these were private queries. Brian >--------- Text sent by Dave Beering follows: > From drbeering@amoco.com Thu Jun 23 04:46:39 1994 > X-Delivered: at request of brian on dxcoms.cern.ch > Date: Wed, 22 Jun 94 21:45:44 CDT > From: drbeering@amoco.com (Dave Beering) > Message-Id: <9406230245.AA00282@boiler.chi.amoco.com> > To: brian > Subject: Urgent Internet Question > > > Brian: > > Thanks for the note. I forwarded your question to Tom Pecelunas, who > heads up our Internetworking group. His response is included below. > I also mentioned to Tom our conversation regarding Amoco's involvement > in the IETF. Tom is very interested. I would not be surprised if we > have someone at the next meeting. > > Please let me know if there is anything else I can provide to you > before you come across. > > Cheers, > > --Dave Beering > > ----------------------------------------------------------------------- > > > From: Tom J. Pecelunas > Telecommunications Internetworking Technology Team > Subject: IP Addressing Question from CERN > > Dave, > > I do not have a good answer to Brian's question on # of user controllable > bytes in an IP address. We currently have 20 class B addresses assigned to us > that we split the 16 bit user portion in half on netting 255 subnets > with 255 addresses per subnet. One additional BYTE would help us in that > we could use the same class B to get up to 65,535 subnets with 255 devices per > subnet. So I guess from Amoco's perspective we would like to have 3 bytes > we can control rather than 2. > > Regards, > > Tom > From brian@dxcoms.cern.ch Thu Jun 23 15:46:45 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA26304; Thu, 23 Jun 1994 09:47:32 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA21150; Thu, 23 Jun 1994 15:46:46 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13515; Thu, 23 Jun 1994 15:46:45 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406231346.AA13515@dxcoms.cern.ch> Subject: Re: Logistics of Workshop #2 To: mankin@cmf.nrl.navy.mil (Allison J Mankin) Date: Thu, 23 Jun 1994 15:46:45 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil, hinden@eng.sun.com In-Reply-To: <199406211719.NAA15842@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Jun 21, 94 01:19:09 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 341 Assuming the plans haven't changed again, how are we going to use the time on Sunday morning? Are we going to agenda bash or subgroupize? If so are we doing it in the Commander? Or is this my chance to re-live the Boston Tea Party? (My side tried to keep the tea in the boat :-) Did I miss the draft agenda, or didn't it come yet? Brian From brian@dxcoms.cern.ch Thu Jun 23 16:05:33 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA26656 for ; Thu, 23 Jun 1994 10:06:08 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA25920; Thu, 23 Jun 1994 16:05:33 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA14087; Thu, 23 Jun 1994 16:05:33 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406231405.AA14087@dxcoms.cern.ch> Subject: Interesting argument for CLNP To: ipng@cmf.nrl.navy.mil Date: Thu, 23 Jun 1994 16:05:33 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1374 In: > From: sra@epilogue.com (Rob Austein) > Newsgroups: info.ietf > Subject: Results of Internet MTU survey > Date: 22 Jun 94 04:03:42 GMT we find: > ================================================================ > > ~Date: Mon, 18 Apr 94 08:48:24 EDT > ~From: sat@eng.tridom.com (Stephen Thomas) > > I'm not sure how relevant this is to your survey, but since you asked.... > > AT&T Tridom provides satellite-based networks that support a wide variety of > protocols, including TCP/IP. When running TCP/IP native over the satellite > links, our MTU size varies but is typically 302 bytes. > > Because this is smaller than the legal minimum of 576 bytes, most of our > customers don't run TCP/IP native. Instead, they encapsulate IP datagrams > within CLNP PDUs and let CLNP perform the segmentation and reassembly. (In > fact, our experience is that so many host IP implementations can't > reassembly correctly, most customers would run CLNP encapsulation if the > satellite links supported any MTU less than 1500.) > > The actual size of our networks is probably proprietary, but we've got on > the order of 10,000 routers on our networks today. I don't have any numbers > on how many hosts are attached. (We own and/or manage the routers; our > customers handle the hosts.) That number is supposed to grow significantly > over the next few years. > Brian From craig@aland.bbn.com Thu Jun 23 07:42:40 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA27361 for ; Thu, 23 Jun 1994 10:45:41 -0400 Received: from port17.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA01042 for ipng@radegond.cmf.nrl.navy.mil; Thu, 23 Jun 94 10:45:19 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id HAA00814; Thu, 23 Jun 1994 07:42:45 -0700 Message-Id: <199406231442.HAA00814@aland.bbn.com> To: sipp@sunroof2.eng.sun.com, ipng@radegond.cmf.nrl.navy.mil Subject: non unicast and EIDs Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 23 Jun 94 07:42:40 -0700 Sender: craig@aland.bbn.com Hi folks: Dumb question -- I've probably just managed to miss the note that explained it. If one uses EIDs, what's are the EIDs for multicast, broadcast and anycast address? Craig E-mail: craig@aland.bbn.com or craig@bbn.com From Bob.Hinden@Eng.Sun.COM Thu Jun 23 08:57:51 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA29956 for ; Thu, 23 Jun 1994 12:49:56 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA26933; Thu, 23 Jun 94 09:49:39 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA15048; Thu, 23 Jun 94 09:00:20 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA16219; Thu, 23 Jun 1994 08:57:51 -0700 Date: Thu, 23 Jun 1994 08:57:51 -0700 From: Bob.Hinden@eng.sun.com (Bob Hinden) Message-Id: <9406231557.AA16219@jurassic.Eng.Sun.COM> To: Christian Huitema Cc: francis@cactus.slab.ntt.jp (Paul Francis), ipng@radegond.cmf.nrl.navy.mil, sipp@sunroof2.Eng.Sun.COM In-Reply-To: <199406230824.AA11335@mitsou.inria.fr> Subject: Re: IPNG ADs' Request to SIPP WG Christian, >I agree completely here. What about paraphrazing Jon's statement: "be liberal >with what you research, conservative with what you standardize". We don't want This is a great quote. Time for a new tee shirt! >to chase two birds with one stone. We have to follow the (proven) IPv4 >strategy when it comes to TCP over SIPP, i.e. use the whole SIPP address. Just right! >Then, we can do research. There are many avenues there, but I am sure that the >solution has to involve authentication. Something like TCP over authentication >over SIPP. In that case, one can rely on the authentication protocol to >provide an "authentication context" and identify the TCP context by a >combination of authentication context and ports, independently of the Internet >addresses. As I said, this is research! I would love to see prototypes; in the >mean time, just play safe, use the whole SIPP address. I agree. I like the notion of combining it with authentication. It is time to start the research/prototype efforts. When they are done and have examined all of the issues and tradeoffs, we can start thinking about standardization. Bob From bound@zk3.dec.com Thu Jun 23 12:48:54 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA00225 for ; Thu, 23 Jun 1994 12:56:00 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA16694; Thu, 23 Jun 94 09:49:10 -0700 Received: by xirtlu.zk3.dec.com; id AA21418; Thu, 23 Jun 1994 12:49:00 -0400 Message-Id: <9406231649.AA21418@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil, Bob.Hinden@eng.sun.com Subject: WHATS THE LOGISTICS Date: Thu, 23 Jun 94 12:48:54 -0400 X-Mts: smtp Scott, Allison, and Bob, HELP... Whats the time of meetings, where are the locations, etc. Its Thursday PLEASE... Also can I get directions to Sun in Mass I need them. In fact I need directions to come into Boston (Sorry I don't do the city culture thing in New England I would rather be with the bears and nature when I have any free time away from my job as a computer focused individual) And I am local I feel real bad for Brian, Lixia, et al flying in. thank you, /jim From ericf@atc.boeing.com Thu Jun 23 10:34:04 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA00884 for ; Thu, 23 Jun 1994 13:31:56 -0400 Received: by atc.boeing.com (5.57) id AA25946; Thu, 23 Jun 94 10:34:04 -0700 Date: Thu, 23 Jun 94 10:34:04 -0700 From: Eric Fleischman Message-Id: <9406231734.AA25946@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: Amoco Cc: ericf Dear Brian, >From the response Amoco gave you, I believe that we are talking apples and oranges. That is, their answer presupposed current IPv4 addressing and indicated what sort of tweak should be made to that addressing structure to better meet their needs. This isn't what we are talking about with IPng -- at least, it isn't what *I* am talking about. I am talking about what addressing structure could (a) meet my corporate needs both now and "indefinitely" in the future while (b) handling toasternet and (c) "indefinitely" meeting the Internet community's needs where "indefinite" is in the order of 20-30 years. It is difficult, of course, for your contacts to respond to queries about addressing on the fly unless they had been thinking about it quite a while. That is, somebody who only does IPv4 addressing thinks in those terms. That person, unless (s)he does addressing for other protocol families as well, is not likely to take two steps back and ask "what addressing schema could best meet my company's needs?" That is, "if the only tool you have is a hammer, all solutions look like a nail." Thus, in many respects the answers you are receiving are predictable. If you are expecting an answer to the types of things which we are concerned about, then your current query method is not likely to bring success -- unless those individuals have been seriously considering the issues for a while. Also, one's conclusion may vary if one believes that convergence is a requirement or not and whether one is concerned with the possibility of toasternet or not. Thus, it is very difficult to even pose the question in such a way that their answer is likely to include a consideration of all of the relevant issues. Sincerely yours, -- Eric Fleischman P.S. Within Boeing there is considerable debate over the merits of various routing/addressing topologies and systems. These are very complex issues and I have done a disservice to the IPng Directorate if I have implied that there is a single or best solution to this complex problem. Of course, such is not the case. Rather, I should have merely stated some addressing assumptions and requirements which I see from my knot-hole. I confess guilt in taking the additional step of concluding that 8 byte SIPP addressing would probably not meet our corporate needs, though, of course, this conclusion represents a Boeing corporate opinion on this topic. Rather, I should have left it up to the community as a whole to take our requirement assumptions and judge the merits of the various approaches to meet these requirements. BTW: I have no problem with 16 byte SIPP addresses and any negative evaluation I put forward of 8 byte SIPP addresses should NOT be extended to imply a problem with the 16 byte SIPP alternative. From dino@cisco.com Thu Jun 23 11:38:19 1994 Return-Path: dino@cisco.com Received: from feta.cisco.com (feta.cisco.com [192.31.7.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id OAA02186 for ; Thu, 23 Jun 1994 14:38:53 -0400 Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA29794; Thu, 23 Jun 1994 11:38:19 -0700 Date: Thu, 23 Jun 1994 11:38:19 -0700 From: Dino Farinacci Message-Id: <199406231838.LAA29794@feta.cisco.com> To: Bob.Hinden@eng.sun.com Cc: Christian.Huitema@sophia.inria.fr, francis@cactus.slab.ntt.jp, ipng@radegond.cmf.nrl.navy.mil, sipp@sunroof2.Eng.Sun.COM In-Reply-To: Bob Hinden's message of Thu, 23 Jun 1994 08:57:51 -0700 <9406231557.AA16219@jurassic.Eng.Sun.COM> Subject: IPNG ADs' Request to SIPP WG >> >I agree completely here. What about paraphrazing Jon's statement: "be liberal >> >with what you research, conservative with what you standardize". We don't want >> >> This is a great quote. Time for a new tee shirt! And add a final clause: "and practical with what you implement". Dino From mankin@radegond.cmf.nrl.navy.mil Thu Jun 23 16:03:58 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id QAA04360 for ; Thu, 23 Jun 1994 16:04:01 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id QAA20354 for ; Thu, 23 Jun 1994 16:03:59 -0400 Message-Id: <199406232003.QAA20354@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil Subject: Rough agenda and replying to some questions Date: Thu, 23 Jun 94 16:03:58 -0400 From: Allison J Mankin Plans are still the same for Sunday. I am thinking about changing the location for Monday to MBONE sites (Harvard on the East side, Sun or Xerox on the West) so we can accomodate Dino, notably. So the plan for Sunday is that those of us who can, will meet at the Commander at 10 in the morning and use the time to brainstorm. The agenda is: Sunday, Transition, including presentation of the new state of SIPP's transition document by Bob Gilligan and Bob Hinden. Monday, the topic of "convergence" with ISO and others (IPX), the requirements on the routing and addressing plan, and Scott and Allison's Choices. We aren't going to do further review or discussion of BigTen address plan or header drafts; that is currently with the working groups. Thanks for allowing this to be a rough agenda. We did well in Chicago, and I think we will also do well with this meeting. At least, Scott and I expect this to be very productive and valuable for getting the draft ready for Toronto. From Bob.Hinden@Eng.Sun.COM Thu Jun 23 17:16:45 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA01723 for ; Thu, 23 Jun 1994 20:18:00 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA01142; Thu, 23 Jun 94 17:17:53 PDT Received: from jurassic.Eng.Sun.COM (jurassic-51) by Eng.Sun.COM (4.1/SMI-4.1) id AA09055; Thu, 23 Jun 94 17:17:31 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA13369; Thu, 23 Jun 1994 17:16:45 -0700 Date: Thu, 23 Jun 1994 17:16:45 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406240016.AA13369@jurassic.Eng.Sun.COM> To: ipng@radegond.cmf.nrl.navy.mil Cc: hinden@Eng.Sun.COM, mankin@cmf.nrl.navy.mil Subject: Location and Times for IPng Directorate Meeting Attached are the locations and times for the IPng Directorate meeting. The meeting will be held in Chelmsford, MA and Mt. View/Menlo Park, CA. There will be a video/audio link between the two sites. I have arranged for Lunch on Sunday and Monday in Mt. View/Menlo Park, and on Monday in Chelmsford. There will be coffee/tea/soda available during the meetings. I will be pageable at (415) 940-8736 in the event of problems. I will send the directions to each site in separate messages. Bob _____________________________________________________ Sunday June 26, 1994 1pm EST to 7pm EST Harvard Video Conference Room Sun Microsystems 2 Elizabeth Drive Chelmsford, MA (508) 442-0052 10AM PST to 4PM PST Gibson Video Conference Room Building 5 Sun Microsystems 2550 Garcia Ave Mt. View, CA (415) 336-2159 _________________________________________________ Monday June 27, 1994 10:30AM EST to 6pm EST Harvard Video Conference Room Sun Microsystems 2 Elizabeth Drive Chelmsford, MA (508) 442-0052 7:30AM PST to 3PM PST Menlo Park Video Conference Room MPK Building 1 Room 260 Sun Microsystems 160 Scott Drive Menlo Park, CA (415) 688-9458 _____________________________________________________ From Bob.Hinden@Eng.Sun.COM Thu Jun 23 17:16:45 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA01720 for ; Thu, 23 Jun 1994 20:17:58 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA01142; Thu, 23 Jun 94 17:17:53 PDT Received: from jurassic.Eng.Sun.COM (jurassic-51) by Eng.Sun.COM (4.1/SMI-4.1) id AA09055; Thu, 23 Jun 94 17:17:31 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA13369; Thu, 23 Jun 1994 17:16:45 -0700 Date: Thu, 23 Jun 1994 17:16:45 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406240016.AA13369@jurassic.Eng.Sun.COM> To: ipng@radegond.cmf.nrl.navy.mil Cc: hinden@Eng.Sun.COM, mankin@cmf.nrl.navy.mil Subject: Location and Times for IPng Directorate Meeting Attached are the locations and times for the IPng Directorate meeting. The meeting will be held in Chelmsford, MA and Mt. View/Menlo Park, CA. There will be a video/audio link between the two sites. I have arranged for Lunch on Sunday and Monday in Mt. View/Menlo Park, and on Monday in Chelmsford. There will be coffee/tea/soda available during the meetings. I will be pageable at (415) 940-8736 in the event of problems. I will send the directions to each site in separate messages. Bob _____________________________________________________ Sunday June 26, 1994 1pm EST to 7pm EST Harvard Video Conference Room Sun Microsystems 2 Elizabeth Drive Chelmsford, MA (508) 442-0052 10AM PST to 4PM PST Gibson Video Conference Room Building 5 Sun Microsystems 2550 Garcia Ave Mt. View, CA (415) 336-2159 _________________________________________________ Monday June 27, 1994 10:30AM EST to 6pm EST Harvard Video Conference Room Sun Microsystems 2 Elizabeth Drive Chelmsford, MA (508) 442-0052 7:30AM PST to 3PM PST Menlo Park Video Conference Room MPK Building 1 Room 260 Sun Microsystems 160 Scott Drive Menlo Park, CA (415) 688-9458 _____________________________________________________ From Bob.Hinden@Eng.Sun.COM Thu Jun 23 17:29:47 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA01911 for ; Thu, 23 Jun 1994 20:30:20 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03167; Thu, 23 Jun 94 17:30:15 PDT Received: from jurassic.Eng.Sun.COM (jurassic-51) by Eng.Sun.COM (4.1/SMI-4.1) id AA11004; Thu, 23 Jun 94 17:29:55 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA14047; Thu, 23 Jun 1994 17:29:47 -0700 Date: Thu, 23 Jun 1994 17:29:47 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406240029.AA14047@jurassic.Eng.Sun.COM> To: ipng@radegond.cmf.nrl.navy.mil Cc: hinden@Eng.Sun.COM, mankin@cmf.nrl.navy.mil Subject: Directions to Sun California Meeting Sites Gibson Video Conference Room Building 5 Sun Microsystems 2550 Garcia Ave Mt. View, CA (415) 336-2159 Directions from San Francisco 1. Travel Highway 101, Southbound 2. Exit at San Antonio Road North (There is a North and a South Exit, South is the second exit) 3. Travel over the freeway. 4. Turn Right at Stop Sign (San Antonio Road) 5. Turn Right at the stop lights (Bayshore Parkway) 6. Turn Left at first street on Left (Garcia Avenue) 7. Past Marine Way, the second Sun building on your left hand side is Building 5. Directions from San Jose 1. Exit at San Antonio Road 2. Turn Right at Stop Sign (San Antonio Road) 3. Turn Right at the stop lights (Bayshore Parkway) 4. Turn Left at first street on Left (Garcia Avenue) 5. Past Marine Way, the second Sun building on your left hand side is Building 5. ________________________________ Menlo Park Video Conference Room MPK Building 1 Room 260 Sun Microsystems 160 Scott Drive Menlo Park, CA (415) 688-9458 I will hand out directions to the Menlo Park site on Sunday. If you are only planning to attend on Monday, please send me email. From Bob.Hinden@Eng.Sun.COM Thu Jun 23 17:29:47 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA01908 for ; Thu, 23 Jun 1994 20:30:18 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03167; Thu, 23 Jun 94 17:30:15 PDT Received: from jurassic.Eng.Sun.COM (jurassic-51) by Eng.Sun.COM (4.1/SMI-4.1) id AA11004; Thu, 23 Jun 94 17:29:55 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA14047; Thu, 23 Jun 1994 17:29:47 -0700 Date: Thu, 23 Jun 1994 17:29:47 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406240029.AA14047@jurassic.Eng.Sun.COM> To: ipng@radegond.cmf.nrl.navy.mil Cc: hinden@Eng.Sun.COM, mankin@cmf.nrl.navy.mil Subject: Directions to Sun California Meeting Sites Gibson Video Conference Room Building 5 Sun Microsystems 2550 Garcia Ave Mt. View, CA (415) 336-2159 Directions from San Francisco 1. Travel Highway 101, Southbound 2. Exit at San Antonio Road North (There is a North and a South Exit, South is the second exit) 3. Travel over the freeway. 4. Turn Right at Stop Sign (San Antonio Road) 5. Turn Right at the stop lights (Bayshore Parkway) 6. Turn Left at first street on Left (Garcia Avenue) 7. Past Marine Way, the second Sun building on your left hand side is Building 5. Directions from San Jose 1. Exit at San Antonio Road 2. Turn Right at Stop Sign (San Antonio Road) 3. Turn Right at the stop lights (Bayshore Parkway) 4. Turn Left at first street on Left (Garcia Avenue) 5. Past Marine Way, the second Sun building on your left hand side is Building 5. ________________________________ Menlo Park Video Conference Room MPK Building 1 Room 260 Sun Microsystems 160 Scott Drive Menlo Park, CA (415) 688-9458 I will hand out directions to the Menlo Park site on Sunday. If you are only planning to attend on Monday, please send me email. From Bob.Hinden@Eng.Sun.COM Thu Jun 23 17:46:17 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA02157 for ; Thu, 23 Jun 1994 20:46:33 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05597; Thu, 23 Jun 94 17:46:28 PDT Received: from jurassic.Eng.Sun.COM (jurassic-51) by Eng.Sun.COM (4.1/SMI-4.1) id AA13378; Thu, 23 Jun 94 17:46:22 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA14697; Thu, 23 Jun 1994 17:46:17 -0700 Date: Thu, 23 Jun 1994 17:46:17 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406240046.AA14697@jurassic.Eng.Sun.COM> To: ipng@radegond.cmf.nrl.navy.mil Cc: hinden@Eng.Sun.COM, mankin@cmf.nrl.navy.mil Subject: Directions to Sun Chelmsford Meeting Site Directions to the Sun Microsystems Chelmsford, Mass. campus Harvard Video Conference Room Sun Microsystems 2 Elizabeth Drive Chelmsford, MA (508) 442-0052 >From Boston ----------- 1. From the South/East (including Boston), get to Route 128. (From Boston the easiest was is to go North on Interstate 93). 2. Note that in some sections Route 128 is also signed as Interstate 95. 3. Proceed round Route 128 to the exit for Route 3 North. (Warning: Route 3 North and Route 3 South are at different exits! 4. Take Route 3 North to the exit for Route 129. 5. At the end of the ramp, turn right and cross back over Route 3. 6. Go through the first set of lights. 7. Almost immediately you will come to a second set of lights, with two left-turn lanes and a left turn signal. 8. Turn left at these lights, then bear right (the road forks). 9. Sun's 2 Elizabeth Drive building will be on your left (you can't miss the big Sun logo). 10.Take the first left into the car park. >From New Hampshire ------------------ 1. From the Route 495 area (e.g. Westford, FTP Software, Interstate 90) or New Hampshire, get to Interstate 495. Follow I-495 to the Route 3 intersection. 2. Take Route 3 South to the exit for Route 129. 3. At the end of the ramp are traffic signals. 4. Turn left here. 5. Almost immediately you will come to a second set of lights, with two left-turn lanes and a left turn signal. 6. Turn left at these lights, then bear right (the road forks). 7. Sun's 2 Elizabeth Drive building will be on your left (you can't miss the big Sun logo). 8. Take the first left into the car park. From Bob.Hinden@Eng.Sun.COM Thu Jun 23 17:46:17 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA02154 for ; Thu, 23 Jun 1994 20:46:30 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05597; Thu, 23 Jun 94 17:46:28 PDT Received: from jurassic.Eng.Sun.COM (jurassic-51) by Eng.Sun.COM (4.1/SMI-4.1) id AA13378; Thu, 23 Jun 94 17:46:22 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA14697; Thu, 23 Jun 1994 17:46:17 -0700 Date: Thu, 23 Jun 1994 17:46:17 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406240046.AA14697@jurassic.Eng.Sun.COM> To: ipng@radegond.cmf.nrl.navy.mil Cc: hinden@Eng.Sun.COM, mankin@cmf.nrl.navy.mil Subject: Directions to Sun Chelmsford Meeting Site Directions to the Sun Microsystems Chelmsford, Mass. campus Harvard Video Conference Room Sun Microsystems 2 Elizabeth Drive Chelmsford, MA (508) 442-0052 >From Boston ----------- 1. From the South/East (including Boston), get to Route 128. (From Boston the easiest was is to go North on Interstate 93). 2. Note that in some sections Route 128 is also signed as Interstate 95. 3. Proceed round Route 128 to the exit for Route 3 North. (Warning: Route 3 North and Route 3 South are at different exits! 4. Take Route 3 North to the exit for Route 129. 5. At the end of the ramp, turn right and cross back over Route 3. 6. Go through the first set of lights. 7. Almost immediately you will come to a second set of lights, with two left-turn lanes and a left turn signal. 8. Turn left at these lights, then bear right (the road forks). 9. Sun's 2 Elizabeth Drive building will be on your left (you can't miss the big Sun logo). 10.Take the first left into the car park. >From New Hampshire ------------------ 1. From the Route 495 area (e.g. Westford, FTP Software, Interstate 90) or New Hampshire, get to Interstate 495. Follow I-495 to the Route 3 intersection. 2. Take Route 3 South to the exit for Route 129. 3. At the end of the ramp are traffic signals. 4. Turn left here. 5. Almost immediately you will come to a second set of lights, with two left-turn lanes and a left turn signal. 6. Turn left at these lights, then bear right (the road forks). 7. Sun's 2 Elizabeth Drive building will be on your left (you can't miss the big Sun logo). 8. Take the first left into the car park. From bill.simpson@um.cc.umich.edu Fri Jun 24 01:09:18 1994 Return-Path: bill.simpson@um.cc.umich.edu Received: from merit.edu (merit.edu [35.1.1.42]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA03029 for ; Thu, 23 Jun 1994 21:41:52 -0400 Received: from pm002-02.dialip.mich.net (pm002-02.dialip.mich.net [35.1.48.83]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA20917 for ; Thu, 23 Jun 1994 21:41:48 -0400 Date: Fri, 24 Jun 94 01:09:18 GMT From: "William Allen Simpson" Message-ID: <2765.bill.simpson@um.cc.umich.edu> To: sipp@sunroof2.eng.sun.com Cc: ipng@radegond.cmf.nrl.navy.mil Reply-to: bsimpson@morningstar.com Subject: Re: IPNG ADs' Request to SIPP WG I'm in the split Identifier/Locator camp. As you can see, there isn't much consensus on this topic. Some hate Identifiers, some think Identifiers will be useful. (Yes Craig, Noel just changed his terminology, but I haven't caught up. I don't understand TSNs yet.) But here's a way I expect we could achieve consensus: Short Term The Identifier and Locator are combined. We will be using IPv4 routing in the backbone, with a 0 prefix on the front. No change. IPAE cum SST will encapsulate SIPP in IPv4 in most places. Medium Term The Identifier and Locator are still combined for fixed nodes, but split for mobile nodes. We will be using IDRP in the backbone(s). SIPP will be routed natively, and IPv4 will be translated to SIPP for improved inter-domain routing. The Identifier will probably have continent-provider-subscriber as the Locator prefix, unless a better plan is developed. The Identifier will be sparsely allocated. Mobile Nodes will not be able to use any Locator in the Identifier. It is a REQUIREMENT for mobility that the Locator and Identifier are split, and that the routing header be used for routing. For Mobile Nodes, the Locator information in the Identifier will be replaced by non-topological "ownership" information. The ownership will parallel the DNS heirarchy for speedy Locator lookup. Long Term The Identifier and Locator will be completely split for all nodes. We don't know how we will route the backbone(s). The Identifier will be densely allocated. ICMP and single UDP messages will use the non-topological ownership information in the Identifier to route slow, high-delay paths. Low delay or other policy setup paths will use Flows. Bill.Simpson@um.cc.umich.edu From Bob.Hinden@Eng.Sun.COM Thu Jun 23 20:14:28 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA04477 for ; Thu, 23 Jun 1994 23:14:42 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20629; Thu, 23 Jun 94 20:14:33 PDT Received: from jurassic.Eng.Sun.COM (jurassic-51) by Eng.Sun.COM (4.1/SMI-4.1) id AA22180; Thu, 23 Jun 94 20:14:34 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA25024; Thu, 23 Jun 1994 20:14:28 -0700 Date: Thu, 23 Jun 1994 20:14:28 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406240314.AA25024@jurassic.Eng.Sun.COM> To: ipng@radegond.cmf.nrl.navy.mil Subject: [gilligan@jurassic.Eng.Sun.COM : Simple SIPP Transition (SST)] I have not seen the final agenda for the Sun/Monday directorate meeting, but I think this will be discussed and wanted to make sure you all saw it. Bob ------- Start of forwarded message ------- From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Sender: sipp-request@sunroof.Eng.Sun.COM To: sipp@sunroof Subject: Simple SIPP Transition (SST) Date: Thu, 23 Jun 1994 16:22:05 +0800 Erik Nordmark, Bob Hinden and I have been working on a simplified transition for SIPP that we think will address most of the issues raised about IPAE. This new proposal is based on IPAE, but provides many simplifications. It includes many ideas suggested by people over the last year. The highlights include: - Complete elimination of table-based IPv4/SIPP address mapping, as suggested by a number of people, especially John Curran. - Elimination of the C-bit, and replacing it with a simplified form of "IPv4 compatible SIPP address", using the 32-bit "C prefix" suggested by Bill Simpson. - The entire 32-bit IPv4 address space is mapped into the SIPP address space under two 32-bit SIPP prefixes. This is similar to the IPv4 address space mapping under one prefix done in CATNIP. - More use of the "dual stack" technique in both hosts and routers. Most hosts and routers would be "dual" for an extended period of time, although they could eventually be converted to SIPP-only. Much of the routing infrastructure would route both SIPP and IPv4 in parallel, although domains could be converted to SIPP-only. - Reliance on global IPv4 routing up until the time when IPv4 addresses run out, as suggested by many people. - Continued use of the SIPP-in-IPv4 encapsulation mechanism proposed in IPAE. - Optional use of the SIPP/IPv4 header translation techniques from IPAE, but without the address mapping feature. Header translation is primarily used to support SIPP-only hosts and SIPP-only routing infrastructures. - No ASEQ (SIPP address) records are needed in the DNS for IPv4 hosts. IPv4 hosts continue to require only A (IPv4 address) records. - The terminology is made more intuitive per suggestion by Jim Bound. - Continues to support completely incremental upgrade of IPv4 hosts to SIPP, and deployment of new SIPP hosts and routers, without any interdependencies, coordination, or flag days. - The term for the new proposal would be "Simple SIPP Transition," with the acronym being SST. This emphasizes the simplicity and stripped-down nature of the proposal, and eliminates the confusion caused by the acronym "IPAE", which was historical. We are in the process of working through the details of this new scheme and putting together a more detailed proposal. We'd like to get some feedback from the group as to whether this looks like a reasonable approach to pursue or not. We have included some of the details that we have worked out below. Please let us know what you think! Note: This proposal is based on 64-bit SIPP. The adaptation to 128-bit SIPP is straightforward. 1. Addressing Two special 32-bit SIPP prefixes are reserved for use as part of the transition. These prefixes are 0:0 (Hex 00000000) and 0:1 (Hex 00000001). SIPP addresses with the prefixes 0:0 and 0:1 hold an IPv4 address in the low-order 32 bits. These addresses are termed "IPv4-compatible SIPP addresses." Only addresses with the prefixes 0:0 and 0:1 are "IPv4-compatible". The addresses of all IPv4-hosts are mapped into the SIPP address space with the prefix 0:0. In other words, a SIPP address of the form 0:0: identifies an IPv4 hosts that has been assigned the IPv4 address . Addresses with the 0:0 prefix show up in packets, but not in the DNS. SIPP "ASEQ" address records are NOT listed in the DNS for IPv4 hosts. IPv4 hosts continue to have only IPv4 "A" records listed in the DNS. The prefix 0:1 is used to assign SIPP addresses to SIPP hosts that wish to interoperate with IPv4 hosts. Any SIPP host that wishes to interoperate with IPv4 hosts must be assigned an address of the form: 0:1: SIPP hosts make use of the IPv4 address embedded in addresses with the prefix 0:1. They use the IPv4 address embedded in their own IPv4-compatible SIPP addresses as an IPv4 source address when sending IPv4 packets. SIPP hosts MAY be assigned additional SIPP addresses. However, only SIPP addresses with the prefixes 0:0 and 0:1 are used as part of the SIPP transition mechanisms. This means that all other prefixes are available for use in a global SIPP addressing plan that is not burdened with transition requirements. For example, an addressing plan for auto-configured addresses that is completely independent of the transition mechanisms could be developed. Addresses with prefixes other than 0:0 and 0:1 are termed "SIPP-only" addresses. SIPP-only addresses MAY embed an IPv4 address if it is convenient to do so, however, the transition mechanisms do not require that or make any use of IPv4 addresses embedded within SIPP-only addresses. SIPP Addressing Summary: IPv4 addr in High 32-bits Low 32-bits? Assigned to What? - ------------ ----------- ----------------- 0:0 Yes IPv4-compatible SIPP address of a IPv4 host 0:1 Yes IPv4-compatible SIPP address of a SIPP host 0:2 through ffff:ffff No SIPP-only address of a SIPP host 2. Encapsulation The SIPP-in-IPv4 encapsulation mechanism from IPAE is retained. 3. Host/Router mechanisms The transition accommodates two types of SIPP hosts and routers: those that implement only SIPP and those that implement both SIPP and IPv4. The base SIPP spec includes some features to allow interoperability between SIPP and IPv4 hosts. For this reason, hosts that implement only SIPP (and do not implement IPv4) may interoperate with IPv4 hosts. However, these SIPP nodes require the assistance of a SIPP/IPv4 header translator. Machines that implement only SIPP are referred to as "SIPP-only" nodes. In addition to requiring a translator, SIPP-only nodes must use an IPv4-compatible SIPP address in order to interoperate with IPv4 hosts. Nodes that implement both SIPP and IPv4 may directly interoperate with IPv4 hosts without the assistance of a header translator. Nodes that implement both SIPP and IPv4 are referred to as "SIPP/IPv4 nodes". SIPP/IPv4 nodes must also use IPv4-compatible SIPP addresses in order to interoperate with IPv4 hosts. SIPP/IPv4 hosts and routers implement several additional transition mechanisms: - They must implement specific rules to determine what format packet (raw SIPP, SIPP-in-IPv4, or raw IPv4) to send, and what the next hop addresses should be. - They may use existing IPv4 address acquisition protocols such as DHCP or BOOTP to acquire their own SIPP address. They first use the protocol to acquire their assigned IPv4 address, then pre-pend the 32-bit prefix 0:1 to that address. The resulting 64-bit value may be used as their own SIPP address. - When sending IPv4 traffic, they may use the low-order 32-bits of any of their addresses with the prefix 0:1 as the IPv4 source address. 4. Header Translation Header translation is an optional mechanism. Header translators are required when SIPP-only hosts are deployed, or when routing domains are converted to route SIPP only. Header translators are not needed in domains that route both SIPP and IPv4, domains that route only IPv4, and domains that have no SIPP-only hosts. Generally speaking, header translators are required at the boundaries of every SIPP-only topology. The mechanics of SIPP-to-IPv4 and IPv4-to-SIPP header translation is similar to that of IPAE, but with some simplifications: - Since only two high-order SIPP prefixes are used, generating a SIPP address is entirely algorithmic and "stateless". There is no need for the "mapping tables" that were a part of the IPAE proposal. - The functionallity of the header translators is currently limited to stub SIPP-only regions. If a need arises, translation for SIPP-only transit regions could also be specified. 5. Transition plan Specifying and implementing the mechanisms are not enough to make the transition happen. A transition plan, which details the individual steps that must be taken to carry out the transition, is needed as well. The transition plan would likely address a number of areas -- e.g., how new addressing plans are deployed, how the routing infrastructure evolves, etc. It would address the time frames in which each step must be carried out, and what interdependencies exist between the steps. Here is a rough outline of what the addressing component of the transition plan might be: Phase I - Well before IPv4 address exhaustion - The Internet continues to use the existing IPv4 addressing plan to assign addresses. SIPP hosts prepend the prefix 0:1 to their assigned IPv4 address and use that as their SIPP address. - One or more SIPP-only addressing plans are developed using prefixes other than 0:0 and 0:1. - SIPP-only addresses MAY be assigned to SIPP hosts in addition to IPv4-compatible SIPP addresses. Phase II - Near IPv4 address exhaustion - SIPP-only IPv4 addressing plans are firmly in place. - All SIPP hosts that require global SIPP connectivity MUST be assigned SIPP-only addresses before IPv4 addresses run out. - SIPP hosts that only require local connectivity do not need to be assigned SIPP-only addresses; they may continue to use IPv4-compatible SIPP addresses. - SIPP hosts that wish to interoperate with IPv4 hosts must keep their IPv4-compatible SIPP address in addition to their SIPP-only address. Phase III - After IPv4 address exhaustion - SIPP hosts must have SIPP-only addresses in order to communicate globally. - SIPP hosts may continue to use IPv4-compatible addresses for local connectivity within a site. Here is a rough outline of how the SIPP routing infrastructure deployment component of the transition plan might be structured: Phase I - Deployment of SIPP/IPv4 infrastructure - The Internet continues to route IPv4 globally. - SIPP routing may be deployed in parallel with IPv4 routing. - IPv4 routers may be upgraded to SIPP/IPv4 at any time. - New SIPP/IPv4 routers may be deployed at any time. - IPv4 hosts may be upgraded to SIPP/IPv4 at any time. - New SIPP/IPv4 hosts may be deployed at any time. - Administrators may set up regions of SIPP-only topology. If they do, they MUST provide header translators at the boundaries of those regions. Phase II - Deployment of SIPP-only infrastructure - Individual sites MAY choose to transition their SIPP/IPv4 topology to SIPP-only, or deploy new SIPP-only topologies. This is entirely optional; All sites may continue to operate a SIPP/IPv4 topology indefinitely if they wish. - A SIPP-only infrastructure may contain no IPv4 hosts. - Whenever a SIPP-only topology is created, SIPP/IPv4 translators must be installed at the boundaries. 6. Documents We think that more than one document is necessary to completely specify the SIPP transition. Our current thinking is that there should be four documents. Quite a bit of the contents of the documents could be derived from the current IPAE spec. The documents we think are needed include: 1) SIPP Transition Overview This would be a short informational paper, probably less than 10 pages, that gives a high-level overview of how the transition works. It would include diagrams showing what packet formats are used in various circumstances. 2) SIPP Transition Mechanisms for Hosts and Routers This would be a detailed specification of the transition mechanisms that hosts and routers would implement. This would be a specification document, written with the standard MUST/SHOULD/MAY wording. This document would be used by people implementing SIPP/IPv4 hosts and routers. 3) SIPP Transition Mechanisms for Header Translators This would be a detailed specification of the transition mechanisms that header translators would implement. This would be a specification document, written with the standard MUST/SHOULD/MAY wording. This document would be used by people implementing header translators. 4) SIPP Transition Plan This would be an informational paper detailing the specific operational steps that must be taken to transition the Internet to using SIPP globally. This paper would include timeframes for the transition. 7. Design Tradeoffs Some of the advantages to this scheme are: - Very low start-up cost. Since the transition begins by using the existing IPv4 addressing plan, virtually all sites can begin deploying SIPP immediately. This provides a simple upgrade path; no renumbering is required. IPv4 hosts simply keep their IPv4 addresses when they upgraded to SIPP. - Easy to understand. All of the mechanisms are fairly easy to understand, so network administrators should be able to implement them without making errors. - Doesn't constrain the long-term SIPP addressing plan. Since the transition mechanisms only occupy two SIPP prefixes, a minuscule fraction of the total SIPP address space, virtually all of the SIPP address space is available to design an efficient SIPP addressing plan. Some of the disadvantages are: - SIPP addresses with 0:0 and 0:1 prefix don't have any more "routing hierarchy" than IPv4. Thus this scheme provides no relief to the IPv4 "route scaling" problem. The general consensus seems to be that CIDR will solve the route scaling problem. - Hosts may require two addresses. In the long term, SIPP hosts that need to interoperate with IPv4 hosts will likely need two SIPP addresses: one with the 0:1 prefix for use interoperating with IPv4 hosts, and another from the "SIPP-only" space for global connectivity. ------- End of forwarded message ------- From brian@dxcoms.cern.ch Fri Jun 24 08:05:19 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA07022 for ; Fri, 24 Jun 1994 02:05:54 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15779; Fri, 24 Jun 1994 08:05:17 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27864; Fri, 24 Jun 1994 08:05:20 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406240605.AA27864@dxcoms.cern.ch> Subject: Re: Amoco To: ipng@cmf.nrl.navy.mil Date: Fri, 24 Jun 1994 08:05:19 +0200 (MET DST) In-Reply-To: <9406231734.AA25946@atc.boeing.com> from "Eric Fleischman" at Jun 23, 94 10:34:04 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 750 Eric, Of course you are correct. As we have said many times, we need more corporate users involved in the process - then we could expect them to understand all the issues. Hidden behind this is another issue, probably the main one, about transition. I asked the Amoco contact "what would you do if Sun announced one day a complete new version of IP, incompatible with the current one?" (Obviously, this will not happen in real life.) His reply "I would call the President of Sun." Even the mildest version of IPng will put many corporate network managers into that state of mind - the most they conceive of is to get one more address byte. I anticipate incredible market resistance to IPng (and I will be one of the resisters, probably). Brian From brian@dxcoms.cern.ch Fri Jun 24 13:11:34 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA11488 for ; Fri, 24 Jun 1994 07:12:08 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24142; Fri, 24 Jun 1994 13:11:32 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA06899; Fri, 24 Jun 1994 13:11:34 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406241111.AA06899@dxcoms.cern.ch> Subject: Where is the Commander, actually? To: ipng@cmf.nrl.navy.mil Date: Fri, 24 Jun 1994 13:11:34 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 169 Somebody, Where is the Commander actually? I have its phone # and I know I have to go to Harvard Square .. then what? A rapid reply would be appreciated! Brian From jcurran@nic.near.net Mon Jun 27 00:36:28 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA09008 for ; Mon, 27 Jun 1994 00:37:33 -0400 Received: from platinum.near.net by nic.near.net id aa19183; 27 Jun 94 0:37 EDT To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: Product from the IPng directorate In-reply-to: Your message of Sun, 26 Jun 1994 23:43:41 -0400. <9406270343.AA22266@xirtlu.zk3.dec.com> Date: Mon, 27 Jun 1994 00:36:28 -0400 From: John Curran Message-ID: <9406270037.aa19183@nic.near.net> -------- ] From: bound@zk3.dec.com ] Subject: Re: Product from the IPng directorate ] Date: Sun, 26 Jun 94 23:43:41 -0400 ] ... ] Again: I would as an individual go in my company and suggest they add ] the cost to TCP/IP product lines for variable addresses if 16bytes will ] not support 30 years without the problem we face with IPng today. Let's assume it does last 30 years... what do you propose we do then? Folks, this isn't _a bridge_ that we're building, it's infrastructure. Engineering rules for single items (whether they be buildings, bridges, or beams) simply do not apply. Think in terms of changing electric power outlets... How long do you want the new design to last? 30 years is _not_ a long time; we'll probably still be upgrading islands of IPv4 then. ] Until I see that kind of hard data moving to variable addresses sticks in ] my throat and I cannot say 'the cost is justified' no matter how great or ] how small. Going from 8bytes to 16 was hard for me, but I was ] convinced of that change, and not just for address space either. I'm not advocating that we use variable length addresses: please forgive me if I gave that impression. I believe that the only acceptable outcome is fixed length addresses, because such addresses meet both the minimal requirements and IETF expectations. /John p.s. I look forward to the IPngNG conference of 2045. Perhaps someone from the directorate can explain why we felt 30 years was enough... From bound@zk3.dec.com Mon Jun 27 01:07:59 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA09499 for ; Mon, 27 Jun 1994 01:11:37 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA29285; Sun, 26 Jun 94 22:09:24 -0700 Received: by xirtlu.zk3.dec.com; id AA22974; Mon, 27 Jun 1994 01:08:05 -0400 Message-Id: <9406270508.AA22974@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Product from the IPng directorate In-Reply-To: Your message of "Mon, 27 Jun 94 00:36:28 EDT." <9406270037.aa19183@nic.near.net> Date: Mon, 27 Jun 94 01:07:59 -0400 X-Mts: smtp ] From: bound@zk3.dec.com ] Subject: Re: Product from the IPng directorate ] Date: Sun, 26 Jun 94 23:43:41 -0400 ] ... ] Again: I would as an individual go in my company and suggest they add ] the cost to TCP/IP product lines for variable addresses if 16bytes will ] not support 30 years without the problem we face with IPng today. >Let's assume it does last 30 years... what do you propose we do then? >Folks, this isn't _a bridge_ that we're building, it's infrastructure. >Engineering rules for single items (whether they be buildings, bridges, >or beams) simply do not apply. Think in terms of changing electric power >outlets... How long do you want the new design to last? 30 years is >_not_ a long time; we'll probably still be upgrading islands of IPv4 then. Well if IPv4 addresses run out in 2005 then thats it right? They may be islands but not part of the Internet? Do we need to make any transition promises or whatever for when IPv4 addresses cannot be globally unique? But 30 years for a product where a protocol is stable is 3 times better than anything else I have seen or know of and thats pretty good. Well if you folks think I was out on star base with EIDs thats nothing. I have a real problem that for the last 10 years of my career I have watched hardware processors increase in performance at a phenomenal rate. Yet software for networking and operating systems have not even kept close to those kind of strides. How about process migration, or if your out of dynamic virtual memory you just get it from your neighbor desk top or from a cluster with reflective memory. I really hope that by 2023 operating systems will have finally left the Von Neuman paradigm and third generation thinking in our industry. I think Locators and EIDs do this in the networking paradigm as we know it today too. For example those of us who are closet Mach freaks know that all the copying done inside the kernel and across user and kernel boundaries is really unecessary. But it would require a major paradigm shift to really figure it out. I will stop here but I sure hope and believe that the network kernel in lets say 2003 will be far beyond what we have for any OS whether its a PC, UNIX, VMS, Router, or any node we can think of presently for IPng. Hence, IPng++ will happen just because IPng is an old idea and can be done so much better its worth changing, which is much different than the IPv4 problem we face today and why we are fixing it. ] Until I see that kind of hard data moving to variable addresses sticks in ] my throat and I cannot say 'the cost is justified' no matter how great or ] how small. Going from 8bytes to 16 was hard for me, but I was ] convinced of that change, and not just for address space either. >I'm not advocating that we use variable length addresses: please forgive >me if I gave that impression. I believe that the only acceptable outcome >is fixed length addresses, because such addresses meet both the minimal >requirements and IETF expectations. OK. I really thought you believed a fixed length address was bad for our health. Really a fan of distributed operating systems research to support distributed networking, and looking for a grant to work on it in a cabin in Maine near Canada where no consensus is needed just some good prototypes, kind of like a modern Henry David Thoreau, where civil disobedience is breaking the Von Neuman hold on software engineering. /jim From mankin@radegond.cmf.nrl.navy.mil Mon Jun 27 08:11:15 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id IAA15676 for ; Mon, 27 Jun 1994 08:11:20 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id IAA05297 for ; Mon, 27 Jun 1994 08:11:18 -0400 Message-Id: <199406271211.IAA05297@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil Subject: Dino's notes on a header Date: Mon, 27 Jun 94 08:11:15 -0400 From: Allison J Mankin Folks, we thought this went out, but apparently not. It may have encountered a mail outage at NRL :( :( This is the notes on the header discussion that took place as a breakout at the Big10 meeting. It resulted from the discussions of the proponent members of the directorate along with their guests. We meant to send it with the "raw minutes". Allison From: Dino Farinacci Message-Id: <199405220352.UAA19291@feta.cisco.com> To: sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil Subject: Notes from packet format meeting at retreat Cc: tli@cisco.com, dkatz@cisco.com, agt@cisco.com, stu@cisco.com, frankm@cisco.com, dino@cisco.com Scott/Allison, here is some spotty notes you asked for from the Header Format meeting on Friday. Dino ------------------------------------------------------------------------ With new address format and to allow for the source route to be implicit in the main header, we had to do some rearranging of the SIPP header. Field requirements: Begin Offset/End Offset: To encode list of intermediate and destination addresses. Flow Id: Relocated to be adjacent to Source address. Payload Type and Hop Limit: Unchanged from SIPP with respect to length. Payload Length: Increased to fit where Flow ID use to be. Intermediate Address: If pointed to by Begin Offset, is the address a router uses to forward on. Address Formats: high-order 3 bits in address determine length of address. Lengths are in 8, 16, 24 byte lengths. We discussed at length if the Flow ID should be present in every packet. Since the semantics of Flow ID are unknown, we were trying to trade-off the extra 8 bytes in the header (to keep addresses 8-byte aligned) with performance considerations when Flows will be used in every day life. Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Offset | Begin Offset | Payload Type | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R L L| | +-----+ -+ | | +- Source Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R L L| | +-----+ -+ | | +- Intermediate Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o o o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R L L| | +-----+ -+ | | +- Destination Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (4-bits): 6 Flags (4-bits): TBD Payload Length (24 bits): Length of packet not including the header. End Offset (8 bits): The byte offset of the byte proceeding the Destination Address. Begin Offset (8 bits): The byte offset of the next address to process in the Destination Address sequence. If Begin Offset is equal to End Offset, there are no more addresses and packet should be discarded if it is not the received system's address. Payload Type (8 bits): SIPP Payload Type values. Hop Limit (8 bits): Same as SIPP. Reserved: Must be sent as zeroes and ignored on receipt. Flow ID: Same semantics as SIPP. Source Address: The address of the system which originiated the packet. Intermediate Address: One or more intermediate systems or clusters that can be traversed to deliver the packet to the Destination. This is used as a loose source route and is a replacement of the Routing Header. Destination Address: The address of the system to receive the packet. Options: Same as SIPP with one exception. The Routing Header is no longer present. From Greg_Minshall@Novell.COM Mon Jun 27 05:54:46 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA16618 for ; Mon, 27 Jun 1994 09:05:03 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA25598; Mon, 27 Jun 94 06:58:32 MDT Received: from [130.57.64.145] (spurcell.wc.novell.com) by WC.Novell.COM (4.1/SMI-4.1) id AA25682; Mon, 27 Jun 94 05:54:49 PDT Date: Mon, 27 Jun 94 05:54:46 PDT Message-Id: <9406271254.AA25682@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@radegond.cmf.nrl.navy.mil, hinden@eng.sun.com, peter@lanl.gov, gilligan@eng.sun.com, nordmark@eng.sun.com, bansal@lkg.dec.com, pvm@isi.edu, conta@zk3.dec.com From: Greg Minshall Subject: What in the world... Everybuggy, I am going to try to put down in writing in a somewhat more organized form what i was ranting about yesterday. Most people probably won't read this till after this morning's (Monday) session, so i may repeat some of this during the session (depending on the direction we take). TERMINOLOGY AND DEFINITIONS There is a host, Ha. It is loaded with some networking software. This could be IPv4 ("V4"), IPv4-compliant IPng ("VG"), or non-IPv4-compliant IPng ("NG"). Ha is assigned an address, Aa. This address could be IPv4 ("V4"), IPv4-compliant IPng ("VG"), or non-IPv4-compliant ("NG"). Ha is attached to a local part of the routing infrastructure, Ra. Ra could be V4, VG, or NG. There is a second host, Hc. It, likewise, is V4, VG, or NG. Hc is assigned an address Ac (which is V4, VG, or NG). Hc is attached to a local (to it) part of the routing infrastructure, Rc (...). Between Ra and Rc is the *rest* of the routing infrastructure, Rb. As in all the above, Rb is V4, VG, or NG. So, the "tuple" to consider is: (Ha, Aa, Ra, Rb, Rc, Ac, Hc). FIRST OBSERVATIONS There are two things from this. First, not that Aa is separate from Ha. Which is to say, you need to be concerned with the tuple (Ha, Aa). Which is to say, we can't just talk about "SST hosts" and/or "SIPP-only hosts" (to use one vocabulary). We need to talk about "SST hosts with SST [0:1] addresses", "SST hosts with non-SST addresses", "SIPP-only hosts with non-SST addresses", and "SIPP-only hosts with SST addresses" (the last of these is of particular interest!). Second, I *suspect* that this defines everything we need to worry about. I *suspect* that we don't need to worry about more complex routing infrastructures - that they will all reduce to one of the above form. THE PROGRAM 3**7 states - 2,187 if my calculator works. I have a *feeling* that if we understand the major subspaces of this state space in terms of how transition works (or doesn't work), we will be in better shape. (You can further decompose a host, Hc say, into say a transport Tc, an internet Ic, and a link/ARP Lc. It is reasonable to assume Ii == Li, i.e., both V4 or both VG or both NG. It is less reasonable, but let us "assume" Ti == Ii.) The first thing to try to do is exclude whole portions of the space. For example, if Aa is V4 but Ha is NG, forget it (depending, unfortunately, on the definition of "Ha == NG"). Here are some other trivial "facts" (or, at least suggestions): If Hi is V4, but Ai is *not* V4, then forget it. {Aa, Ac} == {V4, NG} --> false. {Ra, Rb} or {Rb, Rc} == {V4, NG} --> false. If {Ha, Hc} == {V4, NG}, this *might* work depending on Ai and Ti, and on the availability of translation (theory and practice). {Hi, Ri} == {V4, NG} --> false. DISCLAIMER Note that a *lot* depends on the specific definition of "Hi == NG", etc. Yuck-o. But, that's life. NOTES AND CONCLUSION Lixia pointed out that Ha may be assigned > 1 addresses, Aai, for i = 1, 2, ... I'm not sure if this affects the picture at all. Also, as Peter explained to us, there are *three* components of the internet infrastructure: DNS, routing system, and address assignment. I'm factoring the last two. I've tended to think that DNS, for any given name, is almost certainly in one of three states: only supports IPv4; carries IPng addresses using IPv4 packets; carries IPv4 and IPng addresses in IPv4 and IPng packets. However, there is an *end game* time in which DNS *could* be carrying IPv4 and IPng addresses in only IPng packets for some portions of the DNS name space. And, finally, no, i'm *not* convinced that this is a useful exercise. I suspect it to be, though. I'm not necessarily signing up for this exercise myself, though. Greg From <@www.bbn.com:jcurran@nic.near.net> Mon Jun 27 09:26:09 1994 Return-Path: <@www.bbn.com:jcurran@nic.near.net> Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA17066 for ; Mon, 27 Jun 1994 09:27:15 -0400 Received: from www.bbn.com by nic.near.net id ab25542; 27 Jun 94 9:27 EDT To: ipng@cmf.nrl.navy.mil Subject: Does the 0:1 prefix imply any special processing in SIPP? Date: Mon, 27 Jun 1994 09:26:09 -0400 From: John Curran Message-ID: <9406270927.ab25542@nic.near.net> SIPP/SST requires that systems and routers do non-standard activities with packets sourced or destinated to (what are really IPv4) hosts with a 0:0 address prefix. On the other hand, the 0:1 prefix is actually unrelated, as it is simply an administrative conveniance to provide systems with SIPP addresses as soon as possible. (Oh, yes, and only these addresses will work with IPv4 sites). Does anyone envision doing any code path checking on the fact that a packet is destinated to a SIPP 0:1 prefix as opposed to some other SIPP prefix? /John From ericf@atc.boeing.com Mon Jun 27 09:39:48 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA21175 for ; Mon, 27 Jun 1994 12:37:49 -0400 Received: by atc.boeing.com (5.65) id AA06902; Mon, 27 Jun 1994 09:39:48 -0700 Date: Mon, 27 Jun 1994 09:39:48 -0700 From: Eric Fleischman Message-Id: <9406271639.AA06902@atc.boeing.com> To: bound@zk3.dec.com, jcurran@nic.near.net Subject: Re: Product from the IPng directorate Cc: ipng@cmf.nrl.navy.mil Dear Jim, I don't think that it is possible to prove that 16 bytes aren't enough for IPng unless one wants to imbed very large address spaces of foreign protocols into these addresses. However, what concerns John, me, and others who look back into history is our cumulative inability to predict the future. In our case, if toasternet becomes real then the post-toasternet world may be a whole new ballgame that we can't envision now. Who can predict those needs? The obvious answer of re-designing once we know what that world looks like assumes that the overwhelming new toasternet devices will compell the current inertia to migrate. Again, our experience displays that this is also a fallacy: we still have DECnet Phase III deployed. Rather, unless IPng is well (over) designed, it will be a legacy system. In any case, the IETF can't afford to "jerk around" the users: either we should design an IPng which weathers all unforseen environments or give up the captains seat to some other entity which can design protocols which are adequately robust and flexible to weather unforeseen environments with immense scale. Having said this, I haven't the foggiest idea whether 16 byte addresses or variable length addresses are mandated for the future. I will say, however, that if 16 byte addresses are selected, we had better be mightly careful how the addressing is allocated from that space because it would be quite conceivable to to do addressing within that space in such a clumsy way that 16 bytes couldn't last until 2010 even without a toasternet. Variable length at least permits us to be somewhat stupid -- something which history once again shows that we tend to be. Sincerely yours, --Eric Fleischman From Greg_Minshall@Novell.COM Tue Jun 28 06:16:35 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA05005 for ; Tue, 28 Jun 1994 09:21:22 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA28463; Tue, 28 Jun 94 07:20:14 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB29150; Tue, 28 Jun 94 06:16:35 PDT Date: Tue, 28 Jun 94 06:16:35 PDT Message-Id: <9406281316.AB29150@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Peter S. Ford" From: Greg Minshall Subject: Re: Product from the IPng directorate Cc: ipng@cmf.nrl.navy.mil Peter, Two comments occur to me after reading your document. 1. Where is the CLNPv2 spec? Until there *is* such a spec it is unreasonable for us to consider it. 2. The Chicago meeting had some amount of consensus until about noon. After that, we broke into a transition group and a bits-and-bytes group. I think that consensus went south about that point, especially in the bits-and-bytes group. I think this is just a *fact*, not necessarily good or bad. But, still, a fact that *you* really need to recognize. And, a third comment occurs to me after yesterday's meeting... 3. Due to the miracle of videoconferencing, or my own spaciness, i think i misunderstood some of your ranting and raving yesterday. You were questioning whether or not consensus had been reached, and *i* thought you were questioning SIPP vs. CLNP as the "genetic material base". That seemed a bit bizarre at the time. Later, it occurred to me that you were probably talking about "fixed length" versus "variable length" addresses. If so, i'm sorry i didn't jump in at the time - i agree. I don't think "consensus" has been reached on this issue. I think there are strong, non-fringe, advocates for the variable length argument, just as there are for the fixed length. (I would guess that a *majority* favors fixed length, but consensus is much fuzzier than majority.) Unfortunately, i'm not sure we *can* reach consensus on this particular issue. I, myself, am pulled in both directions - i can't even reach consensus *internally*! Greg From deering@parc.xerox.com Tue Jun 28 09:06:45 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA10124 for ; Tue, 28 Jun 1994 21:04:43 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14517(1)>; Tue, 28 Jun 1994 18:03:56 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 28 Jun 1994 09:07:00 -0700 To: "Peter S. Ford" Cc: ipng@radegond.cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: Product from the IPng directorate In-reply-to: peter's message of Sat, 25 Jun 94 14:25:17 -0800. <199406252025.OAA17879@goshawk.lanl.gov> Date: Tue, 28 Jun 1994 09:06:45 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun28.090700pdt.12171@skylark.parc.xerox.com> > ...fixing SIPP (a worthwhile effort since it was deficient in meeting > even the minimum criteria, routing and addressing the global Internet > of the future). Peter, That's an opinion, not a fact. Steve From Greg_Minshall@Novell.COM Tue Jun 28 09:54:29 1994 Return-Path: Greg_Minshall@Novell.COM Received: from cmsun (cmsun.cmf.nrl.navy.mil [134.207.10.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id MAA06585 for ; Tue, 28 Jun 1994 12:59:12 -0400 Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by cmsun (8.6.8.1/8.6.6) with SMTP id MAA20476 for ; Tue, 28 Jun 1994 12:59:05 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA05330; Tue, 28 Jun 94 10:58:07 MDT Received: from [130.57.64.145] (spurcell.wc.novell.com) by WC.Novell.COM (4.1/SMI-4.1) id AA00539; Tue, 28 Jun 94 09:54:32 PDT Date: Tue, 28 Jun 94 09:54:29 PDT Message-Id: <9406281654.AA00539@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Peter S. Ford" From: Greg Minshall Subject: Re: Product from the IPng directorate Cc: ipng@cmf.nrl.navy.mil Peter, >I am sorry that my behavior was considered to be ranting and raving. I rant and rave. I assume you rant and rave. Its a style, not a character flaw. >It took a lot of patience to not say more in light of the lack of >scrutiny any other proposal than SIPP has been given by the >directorate. (admittedly this is an assessment from watching the >directorate at two retreats, I suspect more inspection has gone on in >the privacy of peoples' crania). This is b.s., but, as you parenthecize, externally this might not be visible. I don't think that, within the directorate, SIPP has been given much more time than TUBA. Greg From peter@goshawk.lanl.gov Tue Jun 28 10:06:34 1994 Return-Path: peter@goshawk.lanl.gov Received: from goshawk.lanl.gov (goshawk.lanl.gov [128.165.96.145]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id MAA06274 for ; Tue, 28 Jun 1994 12:07:03 -0400 Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.9/8.6.4) with SMTP id KAA06202; Tue, 28 Jun 1994 10:06:34 -0600 From: "Peter S. Ford" Message-Id: <199406281606.KAA06202@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: Greg Minshall cc: ipng@cmf.nrl.navy.mil Subject: Re: Product from the IPng directorate In-reply-to: Your message of Tue, 28 Jun 94 06:16:35 -0700. <9406281316.AB29150@WC.Novell.COM> Date: Tue, 28 Jun 94 10:06:34 MST Greg, thanks for your note and please indulge my response. I am fond of calling the Big 10 proposal CLNPv2 because I know it gets peoples receptors turned on, especially the IESG who voted in favor of the OSI-xtnd ban and subsequently reversed themselves. One of these days I will learn when to curb the sarcasm. You are absolutely right in terms of what I feel the core issue to be, which is variable length vrs. fixed length at 16 bytes. What is curious is the tact the directorate is taking which is since "we have consensus on fixed length" (as you noted, there is not such a consensus except within a distinguished subset of the community (self fulfilling consensus?)) we relabel SIPP as IPng. Not only is the truth value of the antecedent suspect, but I would argue the existence of the conditional proposition is suspect in the first place. I am heartened to see a few people step up and concur that there is not this seeming outpouring for fixed length at 16ism that is perceived by the IPng directors. Just out of curiousity, has anyone bothered to poll (not vote, simply poll) the directorate? I can understand that everyone wants this to move forward but it seems to me that at least a reasonable job of evaluating proposals and reporting the results out should occur. Scott and Allison have the big10 proposal. Addressing plan and format have been out as I-Ds for a while. Note, the document was held up by the directors since their view was that it was going to be a contribution from the SIPP group. When this became untenable for the SIPP folks it was written up by others. Big10 is a work in progress in my mind since there are some things that can stand further scrutiny. I think the core thinking of its advocates are: 8,16,24,32 byte addressing elements 16 byte addressing plan for the Internet. Source routing I am sorry that my behavior was considered to be ranting and raving. It took a lot of patience to not say more in light of the lack of scrutiny any other proposal than SIPP has been given by the directorate. (admittedly this is an assessment from watching the directorate at two retreats, I suspect more inspection has gone on in the privacy of peoples' crania). As I stated in my previous note, the IPng process has become a fix-SIPP process. Fortunately, it is beginning to reap some rewards since I think the SIPP proposal is beginning to reach the same level of efficacy as the other proposals on the table at this date. cheers, peter From bound@zk3.dec.com Tue Jun 28 13:24:22 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA06904 for ; Tue, 28 Jun 1994 13:43:37 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA19787; Tue, 28 Jun 94 10:24:42 -0700 Received: by xirtlu.zk3.dec.com; id AA28981; Tue, 28 Jun 1994 13:24:29 -0400 Message-Id: <9406281724.AA28981@xirtlu.zk3.dec.com> To: "Peter S. Ford" Cc: ipng@cmf.nrl.navy.mil Subject: Re: Product from the IPng directorate In-Reply-To: Your message of "Tue, 28 Jun 94 10:06:34 MST." <199406281606.KAA06202@goshawk.lanl.gov> Date: Tue, 28 Jun 94 13:24:22 -0400 X-Mts: smtp Peter, One of the questions on the table is why is not 16bytes fixed enough for 30 years on the Internet. Folks who have tried to prove it is not have been refuted by Bob Hinden and Robert Elz. This is one aspect of the discussion. I personally don't see any more purpose of discussion on the address size. I think the Area Directors should make a decision and from what they outlined yesterday they will have support from the "entire" Directorate. They will also have support from most of the participants on the recent flurry of SIPP mail on the SIPP list which includes some of the TUBA supporters. I think if any Directorate member is not going to support Scott and Allison in Toronto you should send them private mail telling them that so they know up front. Its time to make a decison. TUBA should go away as far as IPng is my opinion and all of us engineers from TUBA, CATNIP, and SIPP should all start working together to get IPng built and tested based on implementations. Architects and those who don't write code should get initial ideas proposed and then get out of the way so we can go build IPng. If folks both write specs and write code great, but I really want to see more discussion between implementors soon or this whole process is really flawed. /jim From <@www.bbn.com:jcurran@nic.near.net> Tue Jun 28 15:09:06 1994 Return-Path: <@www.bbn.com:jcurran@nic.near.net> Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA07922 for ; Tue, 28 Jun 1994 15:10:14 -0400 Received: from www.bbn.com by nic.near.net id aa01403; 28 Jun 94 15:10 EDT To: ipng@cmf.nrl.navy.mil Subject: Re: Product from the IPng directorate In-reply-to: Your message of Tue, 28 Jun 1994 13:24:22 -0400. <9406281724.AA28981@xirtlu.zk3.dec.com> Date: Tue, 28 Jun 1994 15:09:06 -0400 From: John Curran Message-ID: <9406281510.aa01403@nic.near.net> -------- ] From: bound@zk3.dec.com ] Subject: Re: Product from the IPng directorate ] Date: Tue, 28 Jun 94 13:24:22 -0400 ] ] ... ] I personally don't see any more purpose of discussion on the address ] size. I think the Area Directors should make a decision and from what they ] outlined yesterday they will have support from the "entire" Directorate. ] They will also have support from most of the participants on the recent ] flurry of SIPP mail on the SIPP list which includes some of the TUBA ] supporters. ] ] I think if any Directorate member is not going to support Scott and ] Allison in Toronto you should send them private mail telling them that ] so they know up front. Its time to make a decison. I will support Scott and Allison's decision, so long as it is not IPv4. /John From sob@hsdndev.harvard.edu Tue Jun 28 15:13:43 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA07936 for ; Tue, 28 Jun 1994 15:13:52 -0400 Date: Tue, 28 Jun 94 15:13:43 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406281913.AA20507@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: 16 Byte Peter suggested that we do a straw poll of the directorate about 16 byte fixed length addresses being acceptable for IPng (in the context of the revised SIPP proposal and ones own understanding of the 'real world' both technical and political.) That seems like a good idea so here it is Scott & Allison too much ok should be variable J. Allard Steve Bellovin Jim Bound Ross Callon Brian Carpenter Dave Clark John Curran Steve Deering Dino Farinacci Eric Fleischman Paul Frances Mark Knopper Greg Minshall From jcurran@nic.near.net Tue Jun 28 15:41:51 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA08114 for ; Tue, 28 Jun 1994 15:43:27 -0400 Received: from platinum.near.net by nic.near.net id aa04365; 28 Jun 94 15:43 EDT To: Scott Bradner cc: ipng@cmf.nrl.navy.mil Subject: Re: 16 Byte In-reply-to: Your message of Tue, 28 Jun 1994 15:13:43 -0400. <9406281913.AA20507@hsdndev.harvard.edu> Date: Tue, 28 Jun 1994 15:41:51 -0400 From: John Curran Message-ID: <9406281543.aa04365@nic.near.net> -------- ] From: Scott Bradner ] Subject: 16 Byte ] Date: Tue, 28 Jun 94 15:13:43 -0400 ] ] Peter suggested that we do a straw poll of the directorate about 16 byte ] fixed length addresses being acceptable for IPng (in the context of ] the revised SIPP proposal and ones own understanding of the 'real world' ] both technical and political.) That seems like a good idea so here it is ] .. Can I vote once for each name listed below? :-) ] too much ok should be variable ] J. Allard ] Steve Bellovin ] Jim Bound ] Ross Callon ] Brian Carpenter ] Dave Clark ] John Curran X X ] Steve Deering ] Dino Farinacci ] Eric Fleischman ] Paul Frances ] Mark Knopper ] Greg Minshall Enjoy, /John From ericf@atc.boeing.com Tue Jun 28 13:11:44 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA08255 for ; Tue, 28 Jun 1994 16:09:32 -0400 Received: by atc.boeing.com (5.57) id AA06848; Tue, 28 Jun 94 13:11:44 -0700 Date: Tue, 28 Jun 94 13:11:44 -0700 From: Eric Fleischman Message-Id: <9406282011.AA06848@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: 16 Byte Dear Directorate: Here is my answer to the poll: I believe that 16 byte addresses can satisfy our requirements. Many of us in Boeing (including me) would prefer variable length addresses. However, I am not sanguine that such a position could prevail within the IETF. Thus I stand behind Scott and Allison's decision (as Scott explained it to me). Sincerely yours, --Eric Fleischman From bound@zk3.dec.com Wed Jun 29 00:26:16 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA10990 for ; Wed, 29 Jun 1994 00:34:11 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA18519; Tue, 28 Jun 94 21:26:25 -0700 Received: by xirtlu.zk3.dec.com; id AA10636; Wed, 29 Jun 1994 00:26:22 -0400 Message-Id: <9406290426.AA10636@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: 16 Byte In-Reply-To: Your message of "Tue, 28 Jun 94 15:13:43 EDT." <9406281913.AA20507@hsdndev.harvard.edu> Date: Wed, 29 Jun 94 00:26:16 -0400 X-Mts: smtp My answer is OK. /jim From bound@zk3.dec.com Wed Jun 29 01:46:45 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA11263 for ; Wed, 29 Jun 1994 01:53:31 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA21169; Tue, 28 Jun 94 22:46:53 -0700 Received: by xirtlu.zk3.dec.com; id AA11276; Wed, 29 Jun 1994 01:46:51 -0400 Message-Id: <9406290546.AA11276@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Political and Technical and the Directorate Date: Wed, 29 Jun 94 01:46:45 -0400 X-Mts: smtp Scott and Allison, I have heard from several folks that some believe the Directorate is really a political body and not a technical one. I don't agree but this could be viewed this way and that is not good. No I will not tell you who said this to me. I think folks need to realize that many of us have been doing extensive technical reviews of the proposals and this was the spring board for our discussions and conclusions. I think in your presentation you need to do several things as input to you. 1. Make sure the audience clearly understands that we did have much technical evaluation and discussion. I think the archives should reflect that and the con calls. And certainly the last two retreats. 2. Be very cautious to not keep harping on the political overtones of the non-IETF factions except to mention them in passing. I took this to be the advice of Paul M. to us at Retreat #2 too. I agree with Paul completely. 3. Reiterate the technical progress made at the very technical detail level that lead us to 16bytes and SIPP-->IPng. This really started at our dinner meeting in my mind in Seattle, when we all admitted to each other what we liked and did not like technically about each proposal. 4. The White Papers got to some serious technical discussion and produced several technical drafts from members of the Directorate in ID Directory right now. I would not reference the external reveiw panel because that is an embarassement and those folks did NOTHING to contribute to this process at all. Just don't even mention them. Don't give them anything politically either as kudos as all will know its just a political name mention. I do think names like Peter Ford, Bob Hinden, Yakov Rehketer, Dave Katz, Sue Thomson, Frank Kasten, Craig Partridge, Jon Crowcroft, or Tony Li clearly worked their ass off when we asked them too and they should be known to the IETF they helped us out. But if someone did not do something don't give them any credit, just because they are popular or some kind of garbage like that. I think you get the drift of this input. But don't sacrifice your decision by someone standing up and saying it was a political one and not a technical one. I believe it is a technical decision and SIPP just kicked everyones butt with shear hard work on the mailing list and in the working groups. And in addition the SIPP implementors have done a lot of work to share what SIPP is like on a Host. But, at the end of the day gave into the address bandwith bandits so to speak. The last part is just my opinion and clearly can be argued. As far as when you present I think you will be suprised how the IETF will accept your decision and there will be some questions. If those questions come out as an attack or techno-political bottleneck to make it look anyway other than what has been determined, and the question is from a clear supporter of a non-selected proposal who is not just the joe average developer trying to understand what we did, then I will be at the microphone behind them because I do understand how this technically came about. Sorry for the run on sentence. I am very sick of noise without any technical justification or even a valid logic table at this point. I can take noise when it is presented with IMHO and not as fact. Then this is good input to any OPEN process. As someone who has moved new technology products and strategy into two companies I have worked for I have a gut feeling when folks will accept the final decision if its a technical one. I think you guys are cool all the way around. But if you come off to political it could upset the entire decision. People like to hear decisions not positions that cover the presentors butt. take care, /jim From brian@dxcoms.cern.ch Wed Jun 29 09:59:06 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id DAA11656 for ; Wed, 29 Jun 1994 03:59:41 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07086; Wed, 29 Jun 1994 09:59:07 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24614; Wed, 29 Jun 1994 09:59:06 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406290759.AA24614@dxcoms.cern.ch> Subject: SAF/OAF To: peter@goshawk.lanl.gov (Peter S. Ford), ipng@cmf.nrl.navy.mil Date: Wed, 29 Jun 1994 09:59:06 +0200 (MET DST) In-Reply-To: <199406281606.KAA06202@goshawk.lanl.gov> from "Peter S. Ford" at Jun 28, 94 10:06:34 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1081 Folks, I have a suggestion. Could we live with exactly two address formats (distinguished by bits in the IPng header)?: SAF, Standard Address Format (actually SIPP-16) OAF, Optional Address Format (actually NSAPA-32, i.e. a fully conformant NSAPA, not necessarily US-GOSIP, padded out to a maximum of 32 bytes). The applicability statement is: all IPng systems must implement SAF for both source and destination addresses. IPng systems may implement OAF, and if so they must do so for both source and destination addresses. SAF and OAF routing is independent. > Big10 is a work in progress in my mind since there are some things > that can stand further scrutiny. I think the core thinking of its > advocates are: > > > 8,16,24,32 byte addressing elements Overkill in my view (Big10 actually goes up to 56 bytes) > > 16 byte addressing plan for the Internet. Urgent! > > Source routing > Yes, probably no way out, but remember Dave Clark's rather fundamental remarks. > I am sorry that my behavior was considered to be ranting and raving. Not by me. Brian From brian@dxcoms.cern.ch Wed Jun 29 10:02:29 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA11678 for ; Wed, 29 Jun 1994 04:03:37 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07784; Wed, 29 Jun 1994 10:02:30 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24837; Wed, 29 Jun 1994 10:02:29 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406290802.AA24837@dxcoms.cern.ch> Subject: CLNPng To: ipng@cmf.nrl.navy.mil Date: Wed, 29 Jun 1994 10:02:29 +0200 (MET DST) Cc: peter@goshawk.lanl.gov (Peter Ford) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 232 Folks, I would like to suggest that we stop referring to CLNPv2. We should simply state that IPng is (a) IP next generation and (b) a candidate to become CLNP next generation. My OAF suggestion goes with this, of course. Brian From francis@cactus.slab.ntt.jp Wed Jun 29 10:05:04 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA10127 for ; Tue, 28 Jun 1994 21:05:10 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.4); Wed, 29 Jun 1994 10:05:05 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id KAA01019; Wed, 29 Jun 1994 10:05:05 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA29482; Wed, 29 Jun 94 10:05:04 JST Date: Wed, 29 Jun 94 10:05:04 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406290105.AA29482@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: 16 Byte I prefer 16-byte fixed length. PF From brian@dxcoms.cern.ch Wed Jun 29 10:07:41 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA11696 for ; Wed, 29 Jun 1994 04:08:15 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11372; Wed, 29 Jun 1994 10:07:43 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24992; Wed, 29 Jun 1994 10:07:42 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406290807.AA24992@dxcoms.cern.ch> Subject: Re: 16 Byte To: ipng@cmf.nrl.navy.mil Date: Wed, 29 Jun 1994 10:07:41 +0200 (MET DST) In-Reply-To: <9406281913.AA20507@hsdndev.harvard.edu> from "Scott Bradner" at Jun 28, 94 03:13:43 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 579 16 bytes are enough. But an NSAPA option will help sales. BTW I realise that Rob Ullmann's mail is bouncing, but formally doesn't he get a vote? Brian > > too much ok should be variable > J. Allard > Steve Bellovin > Jim Bound > Ross Callon > Brian Carpenter Yes Add NSAPA option > Dave Clark > John Curran > Steve Deering > Dino Farinacci > Eric Fleischman > Paul Frances > Mark Knopper > Greg Minshall > From francis@cactus.slab.ntt.jp Wed Jun 29 10:21:13 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA10206 for ; Tue, 28 Jun 1994 21:21:17 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.4); Wed, 29 Jun 1994 10:21:14 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id KAA01699; Wed, 29 Jun 1994 10:21:13 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA29695; Wed, 29 Jun 94 10:21:13 JST Date: Wed, 29 Jun 94 10:21:13 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406290121.AA29695@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: 16 Byte I should also have mentioned......I'm very pleased that a decision is being made. To be honest, 6 months ago I didn't think it would get done by now. Congratulations to Scott and Alison. I am genuinely looking forward to being able to work *with everybody* in producing the best possible protocol within the context of what has been decided..... PF From bound@zk3.dec.com Wed Jun 29 10:07:28 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA13358 for ; Wed, 29 Jun 1994 10:15:35 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA14437; Wed, 29 Jun 94 07:07:36 -0700 Received: by xirtlu.zk3.dec.com; id AA19781; Wed, 29 Jun 1994 10:07:34 -0400 Message-Id: <9406291407.AA19781@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu Cc: ipng@cmf.nrl.navy.mil Subject: Re: bigten notes In-Reply-To: Your message of "Wed, 29 Jun 94 06:48:07 PDT." <9406291348.AA02849@WC.Novell.COM> Date: Wed, 29 Jun 94 10:07:28 -0400 X-Mts: smtp I would prefer 64bit for the Alpha hardware and now coming Intel/HP chip and I think others on the horizon too. But at least 32bits means I can load a complete 8byte part via a pointer in the implementation. This is one reason I will technically object to any source route in the middle of the dst and src address. That is not smart. Also having dst address before the src address seems prudent for routing. /jim From bound@zk3.dec.com Wed Jun 29 17:32:15 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA17879 for ; Wed, 29 Jun 1994 17:39:00 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA12740; Wed, 29 Jun 94 14:32:25 -0700 Received: by xirtlu.zk3.dec.com; id AA29451; Wed, 29 Jun 1994 17:32:21 -0400 Message-Id: <9406292132.AA29451@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: Dino's notes on a header In-Reply-To: Your message of "Mon, 27 Jun 94 08:11:15 EDT." <199406271211.IAA05297@radegond.cmf.nrl.navy.mil> Date: Wed, 29 Jun 94 17:32:15 -0400 X-Mts: smtp Allison, I can't use the words described about this packet format that my colleagues and I will use if this is even thought about. Its horrible and here are a few inputs to support that adjective. 1. Variable addresses. I have given you plenty on this. 2. End/Offset - Begin/Offset - This is a killer for memory access and reclamation of the packet. I thought all addresses would be aligned on 32bit boundaries. 3. Source route should remain an option in the protocol. Most traffic in the world today and tomorrow will be local is my assumption. Most of my customers applications that use the network are local. Intermediate addresses between the src and dst address will cause additional software on the host to process the packet at the network and transport layer. With variable addresses, byte offset ptrs, src and dst seperated by variable addresses will cause an order of magnitude performance loss on host systems. Telnet will run much faster on IPv4 than IPng and this is not acceptable. If Big-10 goes to the public lists it will receive even more 'dont' do this input from my end. Again its horrible. /jim From deering@parc.xerox.com Wed Jun 29 15:47:28 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA18339 for ; Wed, 29 Jun 1994 18:49:23 -0400 Received: by alpha.xerox.com via suspension id <14466(3)>; Wed, 29 Jun 1994 15:48:41 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14417(5)>; Wed, 29 Jun 1994 15:47:51 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 29 Jun 1994 15:47:40 -0700 To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: BigTen packet format In-reply-to: sob's message of Wed, 29 Jun 94 13:11:30 -0800. <9406292011.AA05301@hsdndev.harvard.edu> Date: Wed, 29 Jun 1994 15:47:28 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun29.154740pdt.12171@skylark.parc.xerox.com> > Here is a writeup we received of the packet format that was talked about > at the end of the BigTen meeting. No it's not. In the format we discussed at the end of the BigTen meeting, the Flow field was not optional, a 32-bit reserved field preceded the Flow field, the Length field was 24 bits wide, the one-byte fields in the second 32-bit word of the header were in a different order, and the Flag values were not defined. The addresses did not have a Strict/Loose indicator or a Locator Family field; they had only a 2-bit Len field preceded by one Reserved bit. This document describes something other than what we discussed at the meeting. Steve From deering@parc.xerox.com Wed Jun 29 17:15:14 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18875 for ; Wed, 29 Jun 1994 20:16:05 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14423(1)>; Wed, 29 Jun 1994 17:15:27 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 29 Jun 1994 17:15:18 -0700 To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: 16 Byte In-reply-to: sob's message of Tue, 28 Jun 94 12:13:43 -0800. <9406281913.AA20507@hsdndev.harvard.edu> Date: Wed, 29 Jun 1994 17:15:14 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun29.171518pdt.12171@skylark.parc.xerox.com> Scott, Technically, I prefer fixed-length 8-byte addresses; politically, I'll go along with fixed-length 16-byte addresses. By the way, your list of Directorate members being polled excluded Lixia and Rob (and maybe others?). Steve From sob@hsdndev.harvard.edu Wed Jun 29 20:22:48 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18903 for ; Wed, 29 Jun 1994 20:22:56 -0400 Date: Wed, 29 Jun 94 20:22:48 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406300022.AA22167@hsdndev.harvard.edu> To: deering@parc.xerox.com Subject: Re: BigTen packet format Cc: ipng@cmf.nrl.navy.mil Humm, I admit that I did not look at the doc, it was represented to me as a description of the discussed packet format. I stand (actually sit) corrected. Scott From sob@hsdndev.harvard.edu Wed Jun 29 21:08:58 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA19123 for ; Wed, 29 Jun 1994 21:09:09 -0400 Date: Wed, 29 Jun 94 21:08:58 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406300108.AA23340@hsdndev.harvard.edu> To: deering@parc.xerox.com Subject: Re: 16 Byte Cc: ipng@cmf.nrl.navy.mil > By the way, your list of Directorate members being polled excluded Lixia and Rob (and maybe others?). blush Scott From Greg_Minshall@Novell.COM Wed Jun 29 18:24:50 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA19212 for ; Wed, 29 Jun 1994 21:29:25 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11852; Wed, 29 Jun 94 19:28:34 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB04686; Wed, 29 Jun 94 18:24:50 PDT Date: Wed, 29 Jun 94 18:24:50 PDT Message-Id: <9406300124.AB04686@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: bigten notes Cc: ipng@cmf.nrl.navy.mil Jim, >I would prefer 64bit for the Alpha hardware and now coming Intel/HP >chip and I think others on the horizon too. But at least 32bits means I >can load a complete 8byte part via a pointer in the implementation. >This is one reason I will technically object to any source route in the >middle of the dst and src address. That is not smart. I don't understand your comment about this being "one reason i will technically object to any source route in the middle of the dst and src address[es]". You seem to want 0%32 or 0%64 alignment. However, assuming the addresses in the source route are, themselves, 0%32 or 0%64, you would still get your alignment, wouldn't you? In that case, why would you technically object? Greg From Greg_Minshall@Novell.COM Wed Jun 29 18:25:39 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA19217 for ; Wed, 29 Jun 1994 21:30:45 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11866; Wed, 29 Jun 94 19:29:22 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB04686; Wed, 29 Jun 94 18:25:39 PDT Date: Wed, 29 Jun 94 18:25:39 PDT Message-Id: <9406300125.AB04686@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: Product from the IPng directorate Cc: ipng@cmf.nrl.navy.mil, "Peter S. Ford" Jim, Sorry to pick on you, but i want to make one last point on variable vs. fixed then i'm "out of here" (given that i don't *really* have a strong position one way or the other), and you happened to "be there". >One of the questions on the table is why is not 16bytes fixed enough for >30 years on the Internet. Folks who have tried to prove it is not have >been refuted by Bob Hinden and Robert Elz. This is one aspect of the >discussion. I think there are two issues which deserve comment. 1. Some people are arguing that 16 bytes fixed is enough bytes for routing for the next 30 years. A careful addressing plan, administered carefully at all levels, and it all works. I don't think *anyone* disagrees with this. In fact, *most of us* would agree that the same is true with 8 bytes. However, the "other side" is arguing that 16 bytes is not enough for a manageable, address assignment mechanism for 30 years (or, *may* not be enough). The strongest argument is that, ultimately, there really isn't enough savvy brainpower to go around, at all levels of all organizations, to "carefully" administer this stuff if "it really takes off". I, personally, don't this this position of the "other side" is susceptible to "proof" or "disproof" in any formal sense. I *do* think there has been more miscommunication on this issue than on most any other issue in recent internet memory (but, i have a notoriously faulty memory). 2. "The difference between theory and practice is that in theory there is no difference, but in practice there is." The strong argument of the "other side" is based on practice. The strongest arguers for the "other side" are the practicioners. *I* am not a practicioner of running networks, either at the provider level or at a large customer site. *You* are not such a practioner. Noel isn't, Allison isn't, Steve D. isn't. Brian C. is. Eric F. is. I think Robert Elz *has* been, but i don't know if he is now. The strongest arguments for "this side" (16 byte fixed) are based on theory. Again, i don't know who is right, and who is wrong. And, yes, of course, this characterization is by no means totally true. But, i've always thought of the IETF's strength as being paying more attention to practice than to theory (when the two went, or seemed to go, separate ways). Greg (doing a lot of venting tonight, for no particular good reason...) From smb@research.att.com Wed Jun 29 21:34:27 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA19253 for ; Wed, 29 Jun 1994 21:35:43 -0400 From: smb@research.att.com Message-Id: <199406300135.VAA19253@picard.cmf.nrl.navy.mil> Received: by gryphon; Wed Jun 29 21:34:28 EDT 1994 To: sob@hsdndev.harvard.edu (Scott Bradner) cc: ipng@cmf.nrl.navy.mil Subject: Re: 16 Byte Date: Wed, 29 Jun 94 21:34:27 EDT Peter suggested that we do a straw poll of the directorate about 16 byte fixed length addresses being acceptable for IPng (in the context of the revised SIPP proposal and ones own understanding of the 'real world' both technical and political.) That seems like a good idea so here it is Scott & Allison too much ok should be variable Circa 20 years ago, I took a computer architecture course from Fred Brooks. From this vantage point, it was one of the most valuable courses I took in grad school, even though I've never actually designed a machine's instruction set, and I doubt I ever will. Among the lessons I learned from Brooks was this invariant: computer architectures *always* run out of address space, and the designers are forced to engage in various hoary hacks to deal with the problem. Furthermore, this pattern has been repeated for every generation of computers; most instruction set designers appear to be incapable of learning from history. I mention this now because the IBM 360 architecture has been with us for about 30 years now, just in time for a very loud debate about whether or not IPng will last 30 years. In my opinion, there's not much doubt about that question -- if IPng is at all a success, it will certainly last more than 30 years. The only thing that will kill it off, other than shortsightedness by its designers, is a technical revolution as fundamental (and as unimaginable in its impact) as the microprocessor. There will simply be too much of it around. 16 bytes isn't enough; anything less is suicidal. I vote for either variable length addresses or 32-byte fixed length addresses. We're designing for the future here, folks; this is IT. From bound@zk3.dec.com Thu Jun 30 01:13:20 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA20245 for ; Thu, 30 Jun 1994 01:16:21 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA29221; Wed, 29 Jun 94 22:13:34 -0700 Received: by xirtlu.zk3.dec.com; id AA03554; Thu, 30 Jun 1994 01:13:27 -0400 Message-Id: <9406300513.AA03554@xirtlu.zk3.dec.com> To: Greg Minshall Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: bigten notes In-Reply-To: Your message of "Wed, 29 Jun 94 18:24:50 PDT." <9406300124.AB04686@WC.Novell.COM> Date: Thu, 30 Jun 94 01:13:20 -0400 X-Mts: smtp >I don't understand your comment about this being "one reason i will >technically object to any source route in the middle of the dst and src >address[es]". You seem to want 0%32 or 0%64 alignment. However, assuming >the addresses in the source route are, themselves, 0%32 or 0%64, you would >still get your alignment, wouldn't you? In that case, why would you >technically object? I want to cache the src and dst addresses. Pretty hard when their in between a long source route. Also we have now extended the packet to 16byte addresses. This is large and I still am hearing arguments for 8bytes on the mail lists and where I work too. But now add a source route to every LAN packet and that becomes unreasonable overhead. Lets not forget the simple SIPP header we all liked. Its is a good short header and real good for most traffic. /jim From bound@zk3.dec.com Thu Jun 30 01:45:24 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA20368 for ; Thu, 30 Jun 1994 01:51:23 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA00307; Wed, 29 Jun 94 22:45:32 -0700 Received: by xirtlu.zk3.dec.com; id AA03749; Thu, 30 Jun 1994 01:45:30 -0400 Message-Id: <9406300545.AA03749@xirtlu.zk3.dec.com> To: Greg Minshall Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil, "Peter S. Ford" Subject: Re: Product from the IPng directorate In-Reply-To: Your message of "Wed, 29 Jun 94 18:25:39 PDT." <9406300125.AB04686@WC.Novell.COM> Date: Thu, 30 Jun 94 01:45:24 -0400 X-Mts: smtp Greg, =>Sorry to pick on you, but i want to make one last point on variable vs. =>fixed then i'm "out of here" (given that i don't *really* have a strong =>position one way or the other), and you happened to "be there". Well I am tired of the discussion and don't feel picked on but getting weary. I am starting to think this is some kind of cosmic test for those really participating in whatever the answer is in the IETF. =>One of the questions on the table is why is not 16bytes fixed enough for =>30 years on the Internet. Folks who have tried to prove it is not have =>been refuted by Bob Hinden and Robert Elz. This is one aspect of the =>discussion. >I think there are two issues which deserve comment. >1. Some people are arguing that 16 bytes fixed is enough bytes for >routing for the next 30 years. A careful addressing plan, administered >carefully at all levels, and it all works. I don't think *anyone* >disagrees with this. In fact, *most of us* would agree that the same is >true with 8 bytes. Yep I think 8bytes will work too. But that won't fly for the compromise and good arguments have been proposed regarding it might not be enough bytes to define hierarchy within the address space of 8 bytes. > However, the "other side" is arguing that 16 bytes is not enough >for a manageable, address assignment mechanism for 30 years (or, *may* not >be enough). The strongest argument is that, ultimately, there really isn't >enough savvy brainpower to go around, at all levels of all organizations, >to "carefully" administer this stuff if "it really takes off". With feelings not logic. I can't relate to the inability of humans to use their tools efficiently whether its computers or any other facet of life. Sorry now we are getting down to philosophy. But I understand. I am willing to give them a margin of error in my mind, and thats why I said OK to 16byte addresses in my reply. And I am not an idealist but a pragmatist. > I, personally, don't this this position of the "other side" is >susceptible to "proof" or "disproof" in any formal sense. I *do* think >there has been more miscommunication on this issue than on most any other >issue in recent internet memory (but, i have a notoriously faulty memory). I would say this brings out peoples true religion and biases about efficiency yes. Nothing we can do about this as folks are diametrically opposed on this issue and I don't think they will agree with each other. I thought 16bytes fixed was a point where we could move forward thats all. Its also a point where I really want to understand its not enough address space for engineering cost reasons, before we go to the next level. >2. "The difference between theory and practice is that in theory there >is no difference, but in practice there is." So what? Does this mean we should have not invented the wheel or how about computers. I have seen this argument in other aspects of my life and folks got killed. The axiom above is a dual edged sword it cuts both ways. The trick is to use that sword in the most efficient manner to defeat your enemy, understanding that each edge serves a different function in battle. No go eat a grapefruit. > The strong argument of the "other side" is based on practice. The >strongest arguers for the "other side" are the practicioners. *I* am not a >practicioner of running networks, either at the provider level or at a >large customer site. *You* are not such a practioner. Noel isn't, Allison >isn't, Steve D. isn't. Brian C. is. Eric F. is. I think Robert Elz *has* >been, but i don't know if he is now. I fully appreciate the input and I think we are listening to these practioners consistently. But I am a practioner of building network products. I designed how I wanted my house built for the money I had. But when the carpenters came in and framers I did not tell them where and how to build the house with the wood. Give me requirements and I will build something and create an engineering design at a cost to me where I can make a profit. Don't ever tell me (Jim) to do anything for the good of society or man kind (we had this discussion on Big-I about 6 months ago). If you have requirements that I can't meet and make a profit I am not going to build the product you want. Someone else may figure it out and thats great and capitialism is great too. [I don't mind doing altruistic things as long as no ones tells me I have to. See books by Ayn Rand - theme is virtues of selfishness, I would save a drowning child because I could not live with myself if I did not try, not because people would think I was a bad person - who cares, not me]. > The strongest arguments for "this side" (16 byte fixed) are based >on theory. And its cheaper to do. > Again, i don't know who is right, and who is wrong. And, yes, of >course, this characterization is by no means totally true. But, i've >always thought of the IETF's strength as being paying more attention to >practice than to theory (when the two went, or seemed to go, separate >ways). Well I don't either really, but thats OK cause we have to make decisions anyway. Sometimes they are right and sometimes they are wrong. But siting around like targets is not my idea of a good time or something I do very well. I would also like to add that many of the forefathers of the IETF who built a successful Internet were practioners too as Researchers, Scientists, and Engineers not just users of what the previous folks create and build. >Greg (doing a lot of venting tonight, for no particular good reason...) But your mail is fun and challenging not annoying and sarcastic. So is your cat really object oriented? /jim From Greg_Minshall@Novell.COM Thu Jun 30 07:00:34 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA22842 for ; Thu, 30 Jun 1994 10:05:41 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA17669; Thu, 30 Jun 94 08:04:17 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB05472; Thu, 30 Jun 94 07:00:34 PDT Date: Thu, 30 Jun 94 07:00:34 PDT Message-Id: <9406301400.AB05472@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: bigten notes Cc: ipng@cmf.nrl.navy.mil Jim, >I want to cache the src and dst addresses. Pretty hard when their in >between a long source route. Also we have now extended the packet to >16byte addresses. This is large and I still am hearing arguments for >8bytes on the mail lists and where I work too. But now add a source >route to every LAN packet and that becomes unreasonable overhead. You mean, you'd like to get the source and destination addresses loaded in the cache, but the cache line size if > 16 bytes, so you are going to have to foul up the cache with "other" crud (source addresses)? Well, it *could* look like src_rt[0] src_rt[1] ... src_rt[n] dest_addr src_addr which puts them next to each other, and correctly aligned. Anyway, thanks for clarifying. Greg From lixia@parc.xerox.com Thu Jun 30 08:13:04 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA23519 for ; Thu, 30 Jun 1994 11:13:55 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14553(3)>; Thu, 30 Jun 1994 08:13:14 PDT Received: by redwing.parc.xerox.com id <57153>; Thu, 30 Jun 1994 08:13:11 -0700 Date: Thu, 30 Jun 1994 08:13:04 PDT Sender: Lixia Zhang From: Lixia Zhang To: ipng@cmf.nrl.navy.mil Subject: Re: 16 Byte In-Reply-To: Your message of Wed, 29 Jun 1994 17:15:14 -0700 Message-ID: > By the way, your list of Directorate members being polled excluded Lixia and > Rob (and maybe others?). > > Steve I'll cast my vote anyway :-) I have made same observations as Greg, i.e. I observed that people in 16-fixed camp mostly (I'm not saying all) fall into two categories, research community(*) or host vendors, and people on "the other side" are (mostly) either router vendors or those who run large networks. * Note what I said here is "some fixed-addr people are from research community". The reverse is not true, i.e. not everyone in research is in this camp. Philosophically, I'm very much in line with fixed-size camp. Ideally (and theoretically), I wish we could design IPng with variable addr at this time (why not, since fixed-size is just a special case of variable size). But the world is never ideal :-( We need IPng designed NOW, and we do not want any risk factors. But we have not reached an agreement on (let alone solving it) EID issues, we have little experience with variable size addresses: I'm off my base here, but how many of those CLNP implementations truly handle variable sizes? How much we know about auto-config in variable address case? ... This list probably can go long. Variable size addr does have its cost in implementation. Sometimes I wonder if this cost made us near-sighted: cache lines gonna go larger, and machines gonna run faster, and everything gonne be cheaper with time; other times I feel this cost is a real issue, you cannot make people sacrifice today for tomorrow. So practically I vote for - go with 16-fixed for now, that's the game we know how to play. - design IPng to provide variable size options, to allow switch over when/if needed. - meanwhile resolve the EID issues (and perhaps others too) From bound@zk3.dec.com Thu Jun 30 11:24:43 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA23736 for ; Thu, 30 Jun 1994 11:33:43 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA23232; Thu, 30 Jun 94 08:24:54 -0700 Received: by xirtlu.zk3.dec.com; id AA13176; Thu, 30 Jun 1994 11:24:49 -0400 Message-Id: <9406301524.AA13176@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil, peter@goshawk.lanl.gov, Bob.Gilligan@eng.sun.com, Bob.Hinden@eng.sun.com, pvm@isi.edu, bansal@netrix.lkg.dec.com, nordmark@jurassic-248.eng.sun.com Cc: bound@zk3.dec.com Subject: DRAFT ONLY Revised Transition Questions from Retreat #2 Date: Thu, 30 Jun 94 11:24:43 -0400 X-Mts: smtp This is my recording and draft only. Peter and Atul had points I did my best to capture so send me corrections where my brain missed the exact wording, I am not a great minute taker. thanks /jim --------------------------------------------------------- IPng Transition Questions: Will the customer be able to have incremental solutions? Should transition be separated into several independent more focused transitions? - Applications Transition - End System Transition - Interior Routing Transition - Exterior Routing Transition - Allocation of Network Numbers - DNS - Network Operator Functions How can the IPv4 address space be used, if at all, for transition? What type of node configurations will be required to begin transition (e.g. Hosts only, Hosts and Routers)? Should exisiting APIs for IPv4 maintain binary compatibility once IPng is turned on? Should Administration and Configuration of the transition be defined clearly and with details? Will supporting both IPng and IPv4 network layers on Hosts ease the transition? What are the alterations to other protocols within the TCP/IP suite to support transition. What tools are needed for operators to support transition? Should encapsulation be used for transition (why/where/how)? Should translation be used for transition (why/where/how)? What parts of IPng must be deployed on the Internet if any before transition can begin? What are the requirements for providers to support IPng Transition? What are the requirements for systems administrators? Should customers be able to begin transition at the end system or at the routing domain for IPng? Will IPng only systems exist that do not contain an IPv4 network layer? Will IPng only systems be able to talk to IPv4 only hosts? Should plug and play be possilbe for routing during transition? Should transition encourage a movement to IPng only routing domains? During transition what will motivate customers to move to IPng as their primary routing protocol to replace IPv4? What are the cost trade-offs for different Transition scenarios? What is the end user perspective on transition? What is the routers vendor perspective on transition? WHat is the operators perspective on transition? What is the providers perspective on transition? Does IPng system discovery have a role to play in IPv4 to IPng transition? Does IPng autoconfiguration have a role to play in IPv4 to IPng transition? What are the performance requirements of transition for each system in the network? Does an application using IPng APIs have to know the other system is speaking IPng? What in IPv4 can we add that will help transition and can we rely on any needed IPv4 features? From mankin@radegond.cmf.nrl.navy.mil Thu Jun 30 11:25:28 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id LAA23649 for ; Thu, 30 Jun 1994 11:25:37 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id LAA04016; Thu, 30 Jun 1994 11:25:34 -0400 Message-Id: <199406301525.LAA04016@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: lixia@parc.xerox.com cc: ipng@radegond.cmf.nrl.navy.mil Subject: re: 16 Byte Date: Thu, 30 Jun 94 11:25:28 -0400 From: Allison J Mankin Lixia, Thanks for the very articulate message and helpful message. Could you describe very specifically what are the possibilities for design of a feature that acts as a "variable length option"? Allison P.S. You understand Scott cut-and-pasted two lines too short, right? From lixia@parc.xerox.com Thu Jun 30 12:03:57 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA25701 for ; Thu, 30 Jun 1994 15:05:03 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14470(6)>; Thu, 30 Jun 1994 12:04:19 PDT Received: by redwing.parc.xerox.com id <57153>; Thu, 30 Jun 1994 12:04:10 -0700 Date: Thu, 30 Jun 1994 12:03:57 PDT Sender: Lixia Zhang From: Lixia Zhang To: Allison J Mankin Cc: ipng@radegond.cmf.nrl.navy.mil Subject: re: 16 Byte In-Reply-To: Your message of Thu, 30 Jun 1994 08:25:28 -0700 Message-ID: > Could you describe very specifically what are the possibilities > for design of a feature that acts as a "variable length option"? I wish I knew all the answer to every problem :-) No I have not thought much in detail, just a gut feeling that this ought be possible (probably ugly though). e.g. how about what SIPP used to do, putting extended part (high order bits) of addresses, self-encoded (length, etc), in options. But support for source routing may have problems (?)... Others are much better experts in twiddling header bits. maybe we can chat this in next teleconf? But we are not supposed to design protocols, right? :-) From bound@zk3.dec.com Thu Jun 30 16:04:32 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA26166 for ; Thu, 30 Jun 1994 16:06:22 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA00888; Thu, 30 Jun 94 13:04:43 -0700 Received: by xirtlu.zk3.dec.com; id AA20866; Thu, 30 Jun 1994 16:04:38 -0400 Message-Id: <9406302004.AA20866@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IPng Engineering Burn Out - Temperature Gauge Date: Thu, 30 Jun 94 16:04:32 -0400 X-Mts: smtp Scott and Allison, I talk to various folks building IPng software and my own folks working with me. Most all have stopped any progressive engineering awaiting Toronto. Plus the engineers are burned out from no decision. This is not good. Its OK for discussions to get burned out which has been going on for 4 years, but now the implementors are getting burned out. Not good. They would like a decision too fyi. It appears that all are awaiting some new specs too. /jim From bound@zk3.dec.com Fri Jun 24 11:43:55 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA16625 for ; Fri, 24 Jun 1994 11:57:52 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA10278; Fri, 24 Jun 94 08:45:26 -0700 Received: by xirtlu.zk3.dec.com; id AA16150; Fri, 24 Jun 1994 11:44:01 -0400 Message-Id: <9406241544.AA16150@xirtlu.zk3.dec.com> To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: Directions to Sun Chelmsford Meeting Site In-Reply-To: Your message of "Thu, 23 Jun 94 17:46:17 PDT." <9406240046.AA14697@jurassic.Eng.Sun.COM> Date: Fri, 24 Jun 94 11:43:55 -0400 X-Mts: smtp Thanks Bob. /jim From bound@zk3.dec.com Fri Jun 24 11:50:34 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA17007 for ; Fri, 24 Jun 1994 12:15:29 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA10630; Fri, 24 Jun 94 08:52:01 -0700 Received: by xirtlu.zk3.dec.com; id AA16341; Fri, 24 Jun 1994 11:50:40 -0400 Message-Id: <9406241550.AA16341@xirtlu.zk3.dec.com> To: bsimpson@morningstar.com Cc: sipp@sunroof2.eng.sun.com, ipng@radegond.cmf.nrl.navy.mil Subject: Re: IPNG ADs' Request to SIPP WG In-Reply-To: Your message of "Fri, 24 Jun 94 01:09:18 GMT." <2764.bill.simpson@um.cc.umich.edu> Date: Fri, 24 Jun 94 11:50:34 -0400 X-Mts: smtp This would support my belief and gut feeling that we are nine months away from defining identifiers and locators. I find an evolution as Bill proposed very acceptable and would give us time to check the implementation affect of identifier/locators. P.S. I still like TCI Transport Connection Identifier. Instead of EIDs or other terms I have heard. /jim From dcrocker@mordor.stanford.edu Fri Jun 24 09:31:32 1994 Return-Path: dcrocker@mordor.stanford.edu Received: from Mordor.Stanford.EDU (Mordor.Stanford.EDU [36.53.0.155]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id MAA17326 for ; Fri, 24 Jun 1994 12:31:57 -0400 Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA15034; Fri, 24 Jun 1994 09:31:28 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jun 1994 09:31:32 -0700 To: bound@zk3.dec.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPNG ADs' Request to SIPP WG Cc: bsimpson@morningstar.com, sipp@sunroof2.Eng.Sun.COM, ipng@radegond.cmf.nrl.navy.mil At 8:50 AM 6/24/94, bound@zk3.dec.com wrote: >P.S. I still like TCI Transport Connection Identifier. Instead of EIDs >or other terms I have heard. gee, how about TSAP? Dave +1 408 246 8253 (fax: +1 408 249 6205) From bound@zk3.dec.com Fri Jun 24 12:58:16 1994 Forwarded: Fri, 24 Jun 94 13:26:21 -0400 Forwarded: "hinden@eng.sun.com " Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA18331 for ; Fri, 24 Jun 1994 13:23:03 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA14279; Fri, 24 Jun 94 09:59:44 -0700 Received: by xirtlu.zk3.dec.com; id AA17730; Fri, 24 Jun 1994 12:58:22 -0400 Message-Id: <9406241658.AA17730@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: Rough agenda and replying to some questions In-Reply-To: Your message of "Thu, 23 Jun 94 16:03:58 EDT." <199406232003.QAA20354@radegond.cmf.nrl.navy.mil> Date: Fri, 24 Jun 94 12:58:16 -0400 X-Mts: smtp Folks, I can't make the brainstorm at commander so I will see you at Sun Sunday. Also Alex Conta and Atul Bansal will be there too. /jim From bound@zk3.dec.com Fri Jun 24 12:58:16 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA18324 for ; Fri, 24 Jun 1994 13:22:53 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA14279; Fri, 24 Jun 94 09:59:44 -0700 Received: by xirtlu.zk3.dec.com; id AA17730; Fri, 24 Jun 1994 12:58:22 -0400 Message-Id: <9406241658.AA17730@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: Rough agenda and replying to some questions In-Reply-To: Your message of "Thu, 23 Jun 94 16:03:58 EDT." <199406232003.QAA20354@radegond.cmf.nrl.navy.mil> Date: Fri, 24 Jun 94 12:58:16 -0400 X-Mts: smtp Folks, I can't make the brainstorm at commander so I will see you at Sun Sunday. Also Alex Conta and Atul Bansal will be there too. /jim From mankin@radegond.cmf.nrl.navy.mil Fri Jun 24 14:08:41 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id OAA19485 for ; Fri, 24 Jun 1994 14:08:51 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id OAA01602; Fri, 24 Jun 1994 14:08:47 -0400 Message-Id: <199406241808.OAA01602@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil, hinden@eng.sun.com, peter@lanl.gov, gilligan@eng.sun.com, nordmark@eng.sun.com, bansal@lkg.dec.com, pvm@isi.edu, conta@zk3.dec.com Subject: East-West IPng Directorate Workshop--11th Hour Mailing Date: Fri, 24 Jun 94 14:08:41 -0400 From: Allison J Mankin Hi, Directorate Attendees: West-- Steve Deering (Monday only) Dino Farinacci x East-- J. Allard Jim Bound Scott Bradner Ross Callon (not Monday) Brian Carpenter Dave Clark Jon Curran Allison Mankin Greg Minshall Rob Ullmann x Lixia Zhang x are maybes. We will stick w/ Picturetel, as much as I wish MBONE would have worked out. Guests: East-- Atul Bansal, Digital, TACIT co-chair Alex Conta, Digital Peter Ford (or maybe West) West-- Bob Gilligan Bob Hinden Paul Mockapetris Erik Nordmark Rough Agenda: The agenda is: Sunday, Transition, including presentation of the new state of SIPP's transition document by Bob Gilligan and Bob Hinden. Monday, the topic of "convergence" with ISO and others (IPX), the requirements on the routing and addressing plan, and Scott and Allison's Choices. We aren't going to do further review or discussion of BigTen address plan or header drafts; that is currently with the working groups. Thanks for allowing this to be a rough agenda. We did well in Chicago, and I think we will also do well with this meeting. At least, Scott and I expect this to be very productive and valuable for getting the draft ready for Toronto. Places and Times: Sunday-- 10:30 AM Sheraton Commander Lobby 1 PM EDT/10 AM PDT Sun (lunch served at Sun-West)-- Sun-East is Chelmsford, Sun-West is Gibson dinners TBD Monday-- 10:30 AM EDT/7:30 AM PDT Sun (lunch served for both) Sun-East is Chelmsford, Sun-West is Menlo Park End Not Too Late Directions (East Coast folks, meet Scott and me at the Commander lobby at 10 AM, and we'll brainstorm first and drive all who want rides to Chelmsford. Those who can't or won't come in to Cambridge, no problem, see you in Chelmsford at 1): > Date: Thu, 23 Jun 94 17:46:17 PDT > To: ipng@radegond.cmf.nrl.navy.mil > cc: hinden@Eng.Sun.COM, mankin@cmf.nrl.navy.mil > > From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) > Subject: Directions to Sun Chelmsford Meeting Site > > Return-Path: Bob.Hinden@Eng.Sun.COM > > > Directions to the Sun Microsystems Chelmsford, Mass. campus > > Harvard Video Conference Room > Sun Microsystems > 2 Elizabeth Drive > Chelmsford, MA > > (508) 442-0052 > > > >From Boston > ----------- > > 1. From the South/East (including Boston), get to Route 128. > (From Boston the easiest was is to go North on Interstate 93). > > 2. Note that in some sections Route 128 is also signed as Interstate 95. > > 3. Proceed round Route 128 to the exit for Route 3 North. > (Warning: Route 3 North and Route 3 South are at different exits! > > 4. Take Route 3 North to the exit for Route 129. > > 5. At the end of the ramp, turn right and cross back over Route 3. > > 6. Go through the first set of lights. > > 7. Almost immediately you will come to a second set of lights, with two > left-turn lanes and a left turn signal. > > 8. Turn left at these lights, then bear right (the road forks). > > 9. Sun's 2 Elizabeth Drive building will be on your left (you can't miss > the big Sun logo). > > 10.Take the first left into the car park. > > > >From New Hampshire > ------------------ > > 1. From the Route 495 area (e.g. Westford, FTP Software, Interstate 90) > or New Hampshire, get to Interstate 495. Follow I-495 to the Route 3 > intersection. > > 2. Take Route 3 South to the exit for Route 129. > > 3. At the end of the ramp are traffic signals. > > 4. Turn left here. > > 5. Almost immediately you will come to a second set of lights, with two > left-turn lanes and a left turn signal. > > 6. Turn left at these lights, then bear right (the road forks). > > 7. Sun's 2 Elizabeth Drive building will be on your left (you can't miss > the big Sun logo). > > 8. Take the first left into the car park. > > > Date: Thu, 23 Jun 94 17:29:47 PDT > To: ipng@radegond.cmf.nrl.navy.mil > cc: hinden@Eng.Sun.COM, mankin@cmf.nrl.navy.mil > > From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) > Subject: Directions to Sun California Meeting Sites > > Return-Path: Bob.Hinden@Eng.Sun.COM > > > Gibson Video Conference Room > Building 5 > Sun Microsystems > 2550 Garcia Ave > Mt. View, CA > > (415) 336-2159 > > > Directions from San Francisco > > 1. Travel Highway 101, Southbound > > 2. Exit at San Antonio Road North > (There is a North and a South Exit, South is the second exit) > > 3. Travel over the freeway. > > 4. Turn Right at Stop Sign (San Antonio Road) > > 5. Turn Right at the stop lights (Bayshore Parkway) > > 6. Turn Left at first street on Left (Garcia Avenue) > > 7. Past Marine Way, the second Sun building on your left hand side is > Building 5. > > > Directions from San Jose > > 1. Exit at San Antonio Road > > 2. Turn Right at Stop Sign (San Antonio Road) > > 3. Turn Right at the stop lights (Bayshore Parkway) > > 4. Turn Left at first street on Left (Garcia Avenue) > > 5. Past Marine Way, the second Sun building on your left hand side is > Building 5. > > > ________________________________ > > Menlo Park Video Conference Room > MPK Building 1 > Room 260 > Sun Microsystems > 160 Scott Drive > Menlo Park, CA > > (415) 688-9458 > > I will hand out directions to the Menlo Park site on Sunday. If you are > only planning to attend on Monday, please send me email. > PS. Where is that sob, I'm having to do all this email! From peter@goshawk.lanl.gov Sat Jun 25 14:25:17 1994 Return-Path: peter@goshawk.lanl.gov Received: from goshawk.lanl.gov (goshawk.lanl.gov [128.165.96.145]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id QAA13256; Sat, 25 Jun 1994 16:25:31 -0400 Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.9/8.6.4) with SMTP id OAA17879; Sat, 25 Jun 1994 14:25:24 -0600 From: "Peter S. Ford" Message-Id: <199406252025.OAA17879@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: mankin@cmf.nrl.navy.mil, sob@harvard.edu Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Product from the IPng directorate Date: Sat, 25 Jun 94 14:25:17 MST Allison, Scott and the directorate, I would like to share with you my perspective of the current IPng context. It is my opinion and my writing, but I believe there are others who share my opinion. At present there has not been any output from the IPng directorate with respect to current set of proposals, in particular there has no input to the TUBA group. Thus, there is no way to determine whether or not TUBA as a proposal meets or does not meet the current criteria for IPng, and how it should proceed to rectify its flaws. The only assessment of TUBA that I know of, is the one made by our working group which was submitted to the IPng directorate. At present it appears to me, admittedly not an unbiased observer, that the focus has been on fixing SIPP (a worthwhile effort since it was deficient in meeting even the minimum criteria, routing and addressing the global Internet of the future). I can imagine (not necessarily agree with) many perceived deficiencies of TUBA: Addresses not 8 byte aligned. Can be fixed in CLNPv2, I don't believe it is a big a problem as made out to be. Addresses not fixed length, therefore inefficient Piscitello's sysid draft addresses what I think is the issue of using sysid for transport identification which would significantly ameliorate the issue of performance since we would then use a split locator/eid structure. Proto field replicated in 2 NSELs Mispercpetion, the proto is in the Source NSEL. dest NSEL is left unspec'ed. CLNP Source routing unacceptable Agreed, to be fixed in v2. 20 byte addresses are a bad length Misperception. We have advocated a new Internet addressing plan, using AFI==ISOC, and let everyone else using *GOSIPs migrate to it. Dave P. made this point at the very first TUBA BOF ... Something that fits into 16 bytes would be a good choice and there is interest in doing this. No Flow id. TBD in v2. Once we know what the heck we are doing with flows. Options hosed. Fixed in v2. Fragging hosed. Piscitello path MTU I-D eliminates its usage in v1. Add frag header for v2. TUBA group not willing to fix TUBA. This is a misperception and a very unreasonable assessment of the professional integrity of the primary TUBA advocates: Mark Knopper, Dave Piscitello, Ross Callon, Yakov Rekhter, Lyman Chapin, Dave Katz, myself, etc.. It should be noted that that we even asked to form a working group in the IETF to fix CLNP and were told that we could not and have worked in what I believe anyone would term a hostile environment. Stating that the TUBA effort has resisted fixing CLNP, including changes to CLNP, is simply wrong. If anything, the IESG should be assessed with the label of not wanting to see CLNP development in the IETF. We have always stated that we would fix things that were broken and that we would add things once we understood what needed to be spec'ed and *how* to spec it. The real problem with much of IPng is what I would call real-time design which is can be very dangerous. TUBA continues to advocate changes to the better: witness Piscitello's Path MTU stuff which effectively eliminates fragging and cleans up the average packet a whole lot. We have stated that we would go to a Catnip/SIP style option style. We stole Catnip's option processing stuff and sent it off to ISO. Etc. We have continued work on auto config, etc. This is not an irrelevant amount of work and does show that TUBA is changing the original CLNP. Documents Lyman has worked hard on springing the documents for electronic (and free) distribution. Members of the group have always had the contingency plan of cutting and running with the documents if ISO proved intransigent. Variable length address performance. Let's entertain the following challenge: Pick two host systems, get fixed length SIPP running on them. Run end to end, user memory to user memory single and multiple threaded benchmarks. Toss in NFS for fun. I would like a system that would let us collect some real performance statistics in terms of where time is being burnt ... Now, Give us the machines and code. We add variable lengthing to the SIPP code and then run the same benchmarks. Alternatively, the original authors can write the new variable length version, and let us have a code walkthrough after benchmarking and dynamic execution stats are collected. I am willing to accept the embarrassment of perhaps not quite matching the performance of fixed length SIPP. Are the " fixed length performance wins" guys willing to take the risk of the opposite result? By the way, eids go a long way to solving the host portion of this problem and it seems to me that sound administration in return for real performance should be considered carefully by the IPng process. Political correctness This is clearly a problem. I am willing to say this in public, but I don't hear much on this topic from the IPng directorate. What is CLNP v2? How about Big10. Big10 looks almost exactly like the CLNPv2 Yakov and I were working on prior to Chicago. We would propose that IPng be CLNPv2 and vice vrs. For the sake of political correctness we would send it over to ISO to see if they want it, but we have always believed that the IETF should be responsible for IPng and for that matter the future protocols of the Internet. ISO/CCITT would simply have to take the output of an IPng working group as the source of the ISO/CCITT standards for CLNPv2. I think people are discounting the impact this would have on bringing the telecom/computer world together on building the future network. We believe that ISO and CCITT will agree to this. I have stated this publicly and also submitted this as an action plan to the IAB for IETF/ISO liaison. So where does this leave us? My interpretation of the process so far has been one of marginalization, fix the proposal that is supposed to be the output while avoiding serious discussion about the other proposals out there. I actually have no major problem with this, as long as it really gets us to a good IPng. If it doesn't then I think it is a shameful state of affairs. SIPP++++++++ (16 byte SIPP) is okay but could be improved by the use of variable length addresses, use the bits currently in use for flow id for header length and some flags (option processing gorp, flow present option, etc.) and I think almost all people would step up to this as IPng. SIPP16 is deficient as far as many people are concerned. At present I feel that TUBA and CATNIP are superior to SIPP16, they better address the technical IPng issues. The issue of losing bits for address lengths is a red herring. My favorite herring (I was just in Scandanavia where breakfast offered 6 kinds of herring) is when you can not even afford to lose one bit (8 vrs 16) yet then say good job of engineering done although we can not tolerate even a factor of 2 loss of efficiency in the addressing plan! I would think we can do better. So what do I recommend? Procedurally? Do your job. Which is to evaluate and report out on proposals. Let's get the evaluations out on B-I mailing lists and out as I-Ds. Why are TUBA and CATNIP the wrong approach? Let's get the warts out and get them fixed. If anyone hadn't noticed, there *is* a convergence going on. Exploit it. Allison states that BIG10 is in the working groups, I have to assume she means TUBA or CATNIP because I don't see it being discussed elsewhere. I would appreciate it going out as an ID ASAP and labelled as a contribution from the TUBA group so we can get going with this. To date we held up publication of the packet spec since we were told that Big10 would be output from the SIPP group. Clearly that is not going to happen. It should not be buried as some note in IPng minutes, please send it out or permit the authors to submit it independently. I expect the directorate to evaluate Big10. The TUBA group can generate an assessment of it if you can't get to it. It should be noted that most "routing people" who have seen it find it superior to anything else on the table at this time. And in Chicago a majority of the people there thought it was the right direction to proceed. Except for the people who subsequently withdrew their support for Big10 (I count Steve D. as the only person I know who has done so, there may be others), there are still many who believe Big 10 is better than SIPP16. What I hear is that they are sick and tired of fighting this issue against what is perceived to be absolute intransigence. I must admit, I often feel this way as well, but I *really* feel that the current fixed length stuff is not the best choice for IPng. 16 bytes *may* work, but I am not interested in *may*, I am interested in knowing for sure we don't get painted into a corner later on. Even some RISC people allow for >1cycle instructions ... Another challenge: how about polling the people who are going to build large global networks and gear for that market and ask them if they want to bet the farm on 16 or make a tradeoff for variable length ... I see a lot of opinion from people who are sincerely interested but have little to lose if they are wrong. Let's ask the heads of NTT, ATT, France Telecom, Cisco, Novell, Microsoft, IBM, Siemens, Alcatel, etc. Let's start behaving as if we are really trying to get the job done for a set of customers, instead of the level of debate we have seen in the last two weeks in e-mail. Would you be willing to send the archives of the last two weeks of the current SIPP and B-I list and say: "look, this is great stuff and we now know the answer is ..."? I can't wait to see the content of the IPng mailing list for the last two weeks. More recommendations (read ramblings). Form an IPng group and let's make this stuff work. (yes, ignore the deadlines, etc. Progress is being made, recognize it and embrace it). If you want consensus, then you really need to focus on building the context for consensus. I don't believe you have that as long as you are pitting well organized camps against each other. Technically we need to make progress on several fronts. Let's get the architecture stuff fairly well set. There are gaps in locator/eid, routing, authentication, etc. There is no need for a packet format prior to these issues getting settled. We can get most of these settled fairly quickly is my sense. Note, I can see a single address element being both locator and eid. You just need to agree on the eid portion and this will probably fall out of the autoconfig stuff. (I think this thing about IEEE 802 not being good enough for a first cut on EIDs is a bit overdone ...). Let's finish fixing FTP and friends. Let's get the API/DNS issues settled. Include locator information. Transition is really coming along, this is a good sign. I can even agree to call the next IPng SIPP! Anyways, I thought it best for all of you to know what is active in my grey matter. regards, peter From jcurran@nic.near.net Sat Jun 25 19:34:30 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA15963; Sat, 25 Jun 1994 19:35:37 -0400 Received: from platinum.near.net by nic.near.net id aa03544; 25 Jun 94 19:35 EDT To: "Peter S. Ford" cc: mankin@cmf.nrl.navy.mil, sob@harvard.edu, ipng@cmf.nrl.navy.mil Subject: Re: Product from the IPng directorate In-reply-to: Your message of Sat, 25 Jun 1994 14:25:17 -0700. <199406252025.OAA17879@goshawk.lanl.gov> Date: Sat, 25 Jun 1994 19:34:30 -0400 From: John Curran Message-ID: <9406251935.aa03544@nic.near.net> -------- Peter, I agree with several of your comments, and would like to add one: If IPv4 had been designed with variable length addressing (or even multiple address formats) in mind, then the entire issue of designing an IPng at this time would be moot. Certainly, it would not be easy to start using these new address formats (due to broken implementations which did not expect such), but we would have been able to tell folks that _full_ IP compliance was required by 200x, and that folks should be looking to their software vendors for a new OS release by that time. Certainly having such variable addresses would have complicated the design of compatible "infrastructure" protocols (such as DNS, routing, and autoconfiguration). Would the additional work yield sufficient returns over the long-term? In my personal opinion, the answer is obviously "Yes." Now we're about to design a new Internet Protocol, and people are concerned about the performance and code impacts of variable length addresses. Such concerns are perfectly reasonable and are quite tangible when compared to the indeterminate threat of some future address depletion using IPng with fixed length addresses. In honesty, I feel that selecting fixed length addresses is a disservice to the future. Some folks have asserted that IPng will not necessarily be around long enough to worry about address depletion; that it will be overcome by events before we run out of N bits worth of address. On the other hand, we've mananged to adapt today's IP to a wide range of conditions, and have overcome almost every hurdle _except_ address depletion. Given that we _do_ know how to assign, route, and manage variable length addresses, selecting fixed length addressing for IPng is simply expedient, and foists the real work of incorporating variable length addressing off to future generations. Adopting fixed-length addresses saves us work, may make our toys run faster, and is quite popular if you have a rather close event horizon. Personally, I would rather pay vendors more to develop protocols which will not experience known failure modes, but then again I have to directly support today's IP users, and intend to be around to help tomorrow's IP users. Recommending fixed-length addresses to the IETF is a bad design decision (for future generations), but sometimes the politically correct choice is the only choice available. /John From bound@zk3.dec.com Sun Jun 26 11:50:52 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA00559 for ; Sun, 26 Jun 1994 14:52:12 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA23551; Sun, 26 Jun 94 08:52:37 -0700 Received: by xirtlu.zk3.dec.com; id AA17967; Sun, 26 Jun 1994 11:50:58 -0400 Message-Id: <9406261550.AA17967@xirtlu.zk3.dec.com> To: John Curran Cc: ipng@cmf.nrl.navy.mil Subject: Re: Product from the IPng directorate In-Reply-To: Your message of "Sat, 25 Jun 94 19:34:30 EDT." <9406251935.aa03544@nic.near.net> Date: Sun, 26 Jun 94 11:50:52 -0400 X-Mts: smtp John, >.......... I would rather pay vendors more to develop protocols which >will not experience known failure modes, but then again I have to directly >support today's IP users, and intend to be around to help tomorrow's IP >users. Recommending fixed-length addresses to the IETF is a bad design >decision (for future generations), but sometimes the politically correct >choice is the only choice available. Pay us? Hmm would this be in the form of a grant or pre-payment for what we are going to build? Would BBN be willing to fund Digital, Sun, and HP to build test IPngs for the greater good of society who will use the Internet? Or is this just an emotional altruistic gesture? Or a political comment? I don't know what you mean? I agree with you that if someone can prove 16bytes technically are not enough for IPng address space then variable addresses are a necessary evil. This has been my position for 3 weeks now. No one has proven to me on any mail list discussion that 16bytes are not enough for 30 years of product generations. So far all I hear are vague statements of feelings in ones gut and arguments stating address space will not be efficiient which has been disproved by other members of the Internet community. Political? Come on John. Who hasn't been. Every time we go down to a discussion of how the code looks people accuse us of being coders on Big-I. In fact I know several engineers who don't even want to bother with the IETF because there are now to many architects and marketing types who don't have a clue about building computer end system or routing products in todays world. Much of the IETF has become completely political. Becuase often its the only way to win an architecture argument. The other way is to produce running code and see how it will integrate and execute with present and near-future products. FYI we built the C code with two compilers to test Craig's pseudo code for variable addresses. Then we disassembled it. It was not just 4 addtional instructions. It was closer to what Alex stated which was 8-16 depending on different tweeks. We have been kind to not send input on Big10 spec. Trust me if this is to be taken serious I really think someone from that spec should sit down with some other folks like Steve Deering, Christian Huitema, and Ramesh Govinden and review it. We did an internal review of the spec and packet format. I would not even send it out unless it were to be taken seriously. It is technically very questionable and not well thought out at all from a host implementation perspective. /jim From <@www.bbn.com:jcurran@nic.near.net> Sun Jun 26 19:33:04 1994 Return-Path: <@www.bbn.com:jcurran@nic.near.net> Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA04630 for ; Sun, 26 Jun 1994 19:34:10 -0400 Received: from www.bbn.com by nic.near.net id aa18537; 26 Jun 94 19:34 EDT To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: Product from the IPng directorate In-reply-to: Your message of Sun, 26 Jun 1994 11:50:52 -0400. <9406261550.AA17967@xirtlu.zk3.dec.com> Date: Sun, 26 Jun 1994 19:33:04 -0400 From: John Curran Message-ID: <9406261934.aa18537@nic.near.net> -------- ] From: bound@zk3.dec.com ] Subject: Re: Product from the IPng directorate ] Date: Sun, 26 Jun 94 11:50:52 -0400 ] ] John, ] ] >.......... I would rather pay vendors more to develop protocols which ] >will not experience known failure modes, but then again I have to directly ] >support today's IP users, and intend to be around to help tomorrow's IP ] >users. Recommending fixed-length addresses to the IETF is a bad design ] >decision (for future generations), but sometimes the politically correct ] >choice is the only choice available. ] ] Pay us? Hmm would this be in the form of a grant or pre-payment for ] what we are going to build? Would BBN be willing to fund Digital, Sun, and ] HP to build test IPngs for the greater good of society who will use the ] Internet? Or is this just an emotional altruistic gesture? Or a ] political comment? I don't know what you mean? It means that if having software which is not broken adds 10% to the cost of the equipment I buy, then it's a bargain. ] FYI we built the C code with two compilers to test Craig's pseudo code ] for variable addresses. Then we disassembled it. It was not just 4 ] addtional instructions. It was closer to what Alex stated which was ] 8-16 depending on different tweeks. 8-16 instructions don't matter to some people. In fact, I would wager that that these extra instructions would not even result in a perceptible performance hit for the vast majority of businesses. /John From bound@zk3.dec.com Sun Jun 26 23:43:41 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA08288 for ; Sun, 26 Jun 1994 23:51:59 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA24880; Sun, 26 Jun 94 20:45:04 -0700 Received: by xirtlu.zk3.dec.com; id AA22266; Sun, 26 Jun 1994 23:43:47 -0400 Message-Id: <9406270343.AA22266@xirtlu.zk3.dec.com> To: John Curran Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Product from the IPng directorate In-Reply-To: Your message of "Sun, 26 Jun 94 19:33:04 EDT." <9406261934.aa18537@nic.near.net> Date: Sun, 26 Jun 94 23:43:41 -0400 X-Mts: smtp >It means that if having software which is not broken adds 10% to the cost >of the equipment I buy, then it's a bargain. Ah but everyone expects IP for free on UNIX systems. I guess we could charge more for IPng and we probably should. >8-16 instructions don't matter to some people. In fact, I would wager >that that these extra instructions would not even result in a perceptible >performance hit for the vast majority of businesses. Well we are off that thread but what you say is not entirely the case. Each enhancement we make to the packet flow of TCP/IP because of IPng will add to the performance loss in the network subsystem. The other point is that this 4 instruction claim was made, just like all router vendors are for variable addresses, or I am worried about 50 years for IPng. The arguments against 16byte fixed addresses are very weak and usually disproved. I also love the way folks say oh variable addresses won't cause a large cost on a Host. What's a large cost? Lets say it takes 2 engineers to alter the network subsystem, test, integrated into product base, and then re-train all engineers to work with variable address data structure fields 1 year. That could cost from a bean counter $300K. Thats lets say 5 engineers salary for a year at a certain level or 5 new engineers one could hire to work on other network products. This is how you look at cost metrics in an engineering company that lives and dies based on product revenues. The point is cost and performance. Its two costs not one. It will also affect the time to deliver IPng. Variable addresses add cost and performance loss to an entire network product line on a host. It needs to be highly justified because we are working from an IPv4 base and that is fixed addresses. Again: Many of us don't develop our operating system code in assembler anymore and hardly any in machine code. To make the compilers more efficient for variable addresses most of us have to go to that group and say gee the IETF decided on variable addresses and can you make the compiler better. They will ask why did they do that? So far I would be embarrassed to even try and explain it. Thats another point be conscious of the changes to IPng not just how affects the router or host network layer engineers but all the other engineers in that organization whose job will have more work because of IPng. Like a compiler group if necessary. I am beginning to think that those who do not do software engineering are hand waving and taking for granted the effort to re-vamp TCP/IP for IPng. Read back on all the mail and see how many folks who actually write code to build products are for variable addresses? I have and come up with two engineers. Again: I would as an individual go in my company and suggest they add the cost to TCP/IP product lines for variable addresses if 16bytes will not support 30 years without the problem we face with IPng today. Until I see that kind of hard data moving to variable addresses sticks in my throat and I cannot say 'the cost is justified' no matter how great or how small. Going from 8bytes to 16 was hard for me, but I was convinced of that change, and not just for address space either. I am really trying to be reasonable here. I have given up on at least three key points for IPng I think should be in IPng as an engineer and wearing my architecture hat: Transport IDs/Locators, Dynamic BIND DNS, and the C bit in IPAE (which I thought was a brilliant use of a bit for IPng transition). And finally accepting 16bytes for IPng which is very large. So I will change my mind and listen to the wisdom of others and move towards group consensus. But on this one I don't see anything that could alter my mind until 16bytes is proven to not be enough for IPng. With Meaning and Sincerity, /jim