CURRENT_MEETING_REPORT_ Reported by Philip Almquist/ Consultant General Issues 1. How is what we do constrained by existing GSA procedures? Not much, apparently, since GSA will probably modify their planned procedures if NIST so recommends. 2. Where should the output of this group go? An RFC, most likely, and we should (and probably can) also get it into the GOSIP User's Guide. 3. Have we gotten foreign comments on the draft paper? Basically, no. This may not be problem since most foreign sites may want to get NSAP addresses from their national authorities rather than the Internet. However, comments from non-US members of the Internet are encouraged. Discussion of the Draft Document Unfortunately, a number of the attendees had been unable to read the paper carefully beforehand, because it was distributed in Postscript that didn't seem to be printable on some printers. The chair promised that this problem would be resolved before the next meeting. Mary Youssef noted that the document did not adequately address how large routing domains should be or will be; nor does it discuss how interdomain routing will be accomplished. It is crucial to understand these issues if we want to design a scheme that will be practical given the political and technical realities of the Internet. Desire for local autonomy will provide a push towards small routing domains (similar in size to IP autonomous systems), whereas the current lack of an interdomain routing protocol will provide a push towards very large routing domains (for example, a regional network and its members might form a single routing domain). Ross Callon suggested that we were overreacting to the lack of an interdomain routing protocol because Internet deployment of OSI would be slow enough that static interdomain routing would work until OSI has a real protocol for this purpose. Tony Hain disagreed, noting that DOE will have 50-100 routing domains once they deploy DECNet Phase V. Rob Hagens spoke strongly against making kludges in our design for the sake of short term workability. Someone pointed out that, for NSAP assignment, we should be concerned about the size of administrative domains rather than routing domains. An ``administrative domain'' is one or more routing domains that share the same NSAP address prefix. Thus, it is the size and distribution of administrative domains that determines how large the Internet can grow before it collapses under the weight of the amount of information that must be carried around in the interdomain routing protocol. It was pointed out that the term "administrative domain" is a politically 1 unwise choice of wording, since it suggests that members of an administrative domain have to cede administrative control of their networks to the administrative domain, when in fact the only thing that has to be centralized is the allocation of blocks of NSAP addresses. For example, a regional network could obtain a block of NSAP addresses and become an administrative domain, allocating chunks of its block of NSAP addresses to individual campuses. The regional would only have to advertise to backbone networks its single block of NSAP addresses (via a single prefix), rather than one or more per campus as is done in the IP world. However, there are some cases where a campus might have a good reason to use NSAP addresses that were not from the regional's block of addresses, but regionals could (and probably should?) charge extra for advertising these addresses to national backbones to discourage address entropy and the resultant excessive growth of routing information in the Internet. However, we need to be sure that we don't create policies which have the side effect of making it expensive for a campus to switch WAN providers without immediately changing the NSAP addresses of all its hosts. The discussion returned to what seems to be the central issue: information explosion. There are two approaches: o minimize the size of the routing information that needs to be conveyed o devote more, faster hardware to exchanging routing information We need to find the proper balance between these two approaches. Ross Callon suggested that most sites will be Internet leaf nodes, so we probably win the most by collapsing data near the leaves of the tree. However, for sites which are very small (and there will be a lot of them) not much collapsing will be possible at the the leaf boundary, so we'll need to have further collapsing farther up the tree to get effective size reduction of the routing data about small sites. It was pointed out that the paper uses a stylized model of the Internet (backbones, regionals, and campuses), that ignores such real world realities as back doors, mid-level networks which are not regionals (eg, CSNET), etc. It isn't immediately clear whether the stylized model leads us to the right conclusions. Tony Hain will try to write up a more realistic model. The issue of how mobile hosts fit into an essentially geographical addressing scheme was brought up and quickly dropped because nobody has a good answer. The issue of whether we need a temporary interdomain routing protocol for the Internet was discussed and deferred to OSI Area Directors and the OSI General Working Group. A draft version of BRP was suggested as a likely candidate. 2 Paul Tsuchiya presented his draft paper, ``Efficient Routing Hierarchies Using Multiple Addresses''. This paper describes a hierarchical address allocation scheme which very strictly mirrors the hierarchical Internet topology. Since a host's address largely determines the route used to get to it, hosts which are accessible via multiple regionals or backbones may be assigned multiple addresses, providing alternate path routing and a primitive form of policy-based routing. The group seemed to find the approach interesting but did not reach a firm conclusion about its applicability. It was agreed that once we start to understand how to do address assignment and run OSI in the Internet we need to somehow disseminate this knowledge to the managers of at least the mid-level networks. One good way to accomplish this might be a tutorial and discussion session at a future IETF meeting. ATTENDEES Philip Almquist almquist@jessica.stanford.edu Lan Bosack bosack@mathom.cisco.com Ross Callon callon@erlang.dec.com Allan Cargille cargille@cs.wisc.edu Martina Chan mchan@mot.com A. Lyman Chapin Lyman@merit.edu Richard Colella colella@osi3.ncsl.nist.gov Curtis Cox zk0001@wnyosi4.navy.mil Ella Gardner epg@gateway.mitre.org Martin Gross martin@protolaba.dca.mil Robert Hagens hagens@cs.wisc.edu Tony Hain hain@nmfecc.arpa David Miller dtm@mitre.org Cyndi Mills cmills@bbn.com Mark Needleman mhnur@vccmvsa.bitnet John Vollbrecht jv@merit.edu Dan Wintringham danw@igloo.osc.edu Richard Woundy rwoundy@ibm.com Mary Youssef mary@ibm.com 3