Re: summary?

J. Noel Chiappa (JNC@XX.LCS.MIT.EDU)
Tue 21 Oct 86 10:51:49-EDT

        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

        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?


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:58 GMT