jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) (10/20/86)
Now that the IETF meeting is over, how about some info from those who were there on the relevant issues (separately, of course) to these lists? Thanks. /jordan
JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") (10/21/86)
Here's a brief summary, but remember that these are my personal memories, and are not official and may contain errors. I also hope I'm not offending anyone by writing this up before the official scribe gets to it; if so I apologise. There were three main topics of discussion; ISO transition, Domain Name transition, and EGP. These were discussed in the three separate workshops; I can report on the last in detail, but did not attend the first two. I will give my understanding of what happened in the first two, but it may contain errors. We also heard a report of the state of the ARPANet, but it doesn't contain much that hasn't already been posted to TCP-IP. The ISO transition scheme is looking at ways to start introducing ISO traffic into the system. As I understand it, the general theory is that they will upgrade the routers (IP gateways) to handle ISOgrams as well as IPgrams and run the two protocols side by side; there are also plans for service-level protocol converting gateways for things as mail. There is also an extant spec for using Dod IP addresses in ISOgrams (the ISO addressing architecture is pretty kitchen sink style, and why assign new numbers when we already have perfectly good numbers). The Domain Name transition is coming along pretty well. There are several steps seen as needing to happen; the last non-domain style names need to be flushed from HOSTS.TXT, and the MILNET needs to transition toward use of domain names (at the moment they all use HOSTS.TXT, and if you send mail from a host which is not in HOSTS.TXT to the MILNET they can't reply). Once everyone is using the domain system we can flush HOSTS.TXT. Some issues which were discussed were the need to provide more root servers on the East coast and also root servers on MILNET (to keep the security concious people happy). Also, it is proving difficult for the NIC to build a tree walker that automatically constructs HOSTS.TXT by walking the name tree since lots of people don't support zone transfer. As far as EGP goes, discussion centered around two main topics. One was that the updates are nearing overflow; the entire routing table is sent in a single packet, and as the net gets larger that will overflow. The other was that the current topology restrictions in EGP (you aren't suuposed to have Autonomous Systems in cycles (loops), or more than one AS away from the Core) are crippling. The first was solved by designing an update mechanism where the table is sent slowly, in smaller packets spead out evenly. This has the added advantage of not causing a big processing disturbance when you get this massive table that you have to parse. Everyone who reviewed this thought that it was a good mechanism, and it is close enough to existing algorithms and solving a sufficently simple problem that it was felt that it could be implemented with the assurance that it will work. The problem is that the people who were studying the cycle problem decided that to really fix that right, they needed to switch to a different routing algorithm, which would demand entirely different data in the updates. However, that is a sufficiently complex problem (and algorithm) that it was felt that extensive review, analysis and simulation were needed before the solution was felt to be solid. Such an effort would consume some months, and was thus not amenable to doing on the spot in the committee. This presented a problem, and caused a heated discussion. It was argued that the cycle restrictions were so onerous, that as soon as a solution had been designed it should be implemented right away. The timeframe for that was felt to be a year or two (allowing for design, review, simulation to prove correct functioning, implementation and deplyment). It was further argued that the update size restriction is not that onerous; the updates would not be larger than the MTU of most nets (e.g. ARPANet) for at least a year, and even after that they could be handled by use of IP fragmentation. That being the case, it was felt that diverting effort into an intermediate standard that did not solve the most pressing problem was not a wise move. It was counterargued that if the new design effort failed, we would have failed to solve the one problem we did agree on a solution for, and it would be too late at that point to attempt a crash deployment (due to release schedules, etc). The following compromise was sort of agreed on, after much blood over the transom. A spec will be written for the interim EGP; this will be an official IP spec. BBN will move to get it in the next core gateway release. However, the older version of EGP will be continue to be supported, and it will not be mandatory to implement the new version. In addition, a small number of mandatory upward compatible changes to the existing spec were agreed on to a) make version numbers useful, and b) allow version negotiation. These will all be available for comment in an RFC, to be followed by changes to the EGP RFC. At the same time, a group of interested parties will start work on the followon protocol (FGP), with a target of 6 months to a year to begin deploying it. The proposal will be available for review, but will not be an official spec. Should it prove good enough, it may be adopted as a spec, but that is not guaranteed. Should it be adopted, it would not be necessary to implement the interim standard; users could skip straight from the old one to the new one. This group is private, but will make every effort to consult people on requirements as well as to get reviews of the design. FGP will retain the basic EGP model; groups of gateways called TAS's (transit autonomous systems) will be hooked via FGP, but can run any protocol of their own devising between themselves. The FGP routing algorithm will be based on the existing SPF algorithm done by BBN for the IMPs, and will provide support for cycles, and if possible, TOS and multi-path routing. A means was devised to phase it in gradually; groups of TAS's running it will appear as a single AS using the existing EGP, and will need to be hooked directly to the existing Core. However, within the limits of that AS (which might eventually expand to contain most of the Internet) the new rules will apply. As far as my memory goes, that was about it, although I will admit that I was mostly preoccupied with the EGP thing. I may have missed other topics; if so, would knowledgeable people please comment? Noel -------