Bodega Bay, Ca, U.S.A.
The following is not structured as minutes of the meeting per se - the intent of these notes is to outline the topics covered and the relevant outcomes and actions that may be taken up.
Geoff Huston
Attached is a very brief summary of the meeting.
The MAE-EAST Exchange pilot activity is operating in the Washington DC area, providing a first resort for routing exchanges and a last resort for data for the participants. Work is continuing on the use of an EBONE Route Server deployed on this exchange. The Exchange is self-funded by the participants. Discussion included the scalability of the exchange, noting that route flaps are causing a high level of route recalculation on the part of the exchange routers. Discussion also included various models which could extend the GIX, using either an extension of the Address Bus using Layer 2 extension, or using replicated exchanges with connections provided only by transit providers.
It is noted that in the global context this structure addresses a routing scaling issue. It does introduce issues of single points of potential failure, and does not address the global transit issue per se.
Daniel presented the role of the RIPE NCC. Copies of his overheads are on ftp.ripe.net, and the RIPE-81 document also contains a description of this effort. The RIPE NCC is both a number registry and a routing / policy registry (using preferred AS Path registration). A number of tools to both check the routing database for consistency and to generate router configurations are in development by the RIPE NCC.
Jun Murai presented the establishment of JPNIC in Japan and the extension of this to a regional registry with the APNIC experiment - the regional work is intended to be distributed with JPNIC undertaking net number registration and KRNIC undertaking routing registry activities.
The potential relationships of the European route server work and the routing registries with the current NSF Solicitation for the NAP architecture were noted.
Routing Registries are seen as playing an integral role in the maintenance of policy integrity, and the registries are therefore undertaking the role of the major support vehicle for external routing in the Internet.
The work of the routing registry should be further disseminated in the Internet community, and the RIPE-81 paper is seen as being an important paper to further this dissemination.
The organisational structure of Europanet was described, outlining the roles of Dante Inc, the Unisource provider, the X.25 and IP Unidata service and the EMPB service which is being offered in a CUG configuration within Europe to national academic and research providers. Production turnover of the trial service is anticipated to occur in September 1993.
EBONE is still undertaking the role of a pan-European IP backbone, providing a policy-free European service and providing operational support and coordination services to a number of connecting trans-Atlantic T1 IP links.
Potential connectivity issues between Europanet and EBONE were discussed and the overall operational coordination with respect to routing was highlighted.
Specification of European interconnection is a prerequisite for further activity relating to coordinated European routing and coordinated global Internet routing.
The status of BGP deployment on the NSFNET by ANS was reported. ANS will be deploying CIDR routing tables with GateD routing in October. (Overheads are attached).
The basic message to providers is "CIDR, Default or Die". Other issues highlighted include the difficulty in attempting dis-aggregation of aggregated routes (which implies that providers not using Default to implicitly collect aggregated routes should deploy CIDR in synchronisation with each other), the increased operational costs associated with partial CIDR deployment, and the role of the registry to generate accurate aggregation routing configurations.
BGP4 issues will be further examined within the scope of the IETF, and the deployment issues will be examined at the forthcoming US Regional Techs meeting
Steve Deering was invited to attend the meeting to report on the MBONE and associated issues. (Slide summary is attached).
The nature of the use of the infrastructure by high bandwidth UDP audio and video flows on both a local and global scale were discussed, and recent problems with uncontrolled signal generators were highlighted. Some solution directions were highlighted with refinement of the routing tools (tree pruning within DVMRP) and token-based control of signal generation. Overall global low control is controlled by a single TTL control structure, which is a somewhat crude tool to use to exercise resource control. Development of more specific control protocols for multicast is being developed within the IETF.
The potential efficiencies of multicast for data transfer were highlighted, and applications which implement reliable data transfer within a multicast environment were discussed
Further discussion of these issues is being undertaken within the [email protected] mailing list.
Richard highlighted a lack of coordination activities within the internet-deployed NSAP space, an issue which has become more visible with the growth of the TUBA pilot deployment project.
Richard noted the need for Internet Registries to register and maintain registered NSAP addresses which can assist in both the current techniques of static routing of CLNP traffic and the generation of router configuration tables to underlie future intentions to move to dynamic routing within this area.
The NSAP structuring was also discussed, with noting that the country-based NSAP prefixes and potential Internet NSAP prefixes will probably require coordination within the CLNP routing space.
The role of Internet Registries within the area of NSAP registration was noted, and Richard Colella, Daniel Karrenberg and Elise Gerich indicated they would followup in this area with a review of the role of the registry in this area.
The use of CIDR to trawl the unused address space was also discussed, noting that the knowledge base on this issue is weak and the issue of whether host software requires CIDR awareness in order to function correctly is not well explored. Existing tools also require refinement, both operational tools and registry tools.
It was also noted that the registries are the only point were CIDR information can be generated cleanly, and furthermore it was noted that in order to do so the registry must have a complete knowledge base regarding the local domain of responsibility.
Further investigation is required in this area is evidently required, and the role of the registry in the generation of the CIDR routing domain requires documentation.
The IEPG discussed whether there was a role within the Internet for an organisation to function with operational authority to ensure that end to end service was maintained within defined parameters of quality of service by the service provider community.
The discussion highlighted the difficulties in establishing such authority within the Internet community and the consequent issues of liabilities and the potential for cartel formation. The conclusions drawn from this discussion is that it is not possible within the Internet environment to mandate authority.
The IEPG saw itself as a forum where operational issues can be discussed within a provider environment, but the conclusions of such discussions from the IEPG perspective are simply phrased at most as recommendations which individual providers may find useful to implement in some form or other in a coordinated fashion.
The RIPE NCC effort at a Generic Internet Service Description was noted. The document is intended to describe the "state of the art" in the provision of specific elements of an Internet service, and while the overall structure of the document is complete the document is seen as a edited effort where input within each service description element is solicited from IEPG members.
The issue of the hierarchical relationship with the CCIRN was discussed, and the IEPG was of the view that there is a requirement to take the current broad participation structure and assert a role within the Internet as a whole. This would not preclude the CCIRN requesting the IEPG to examine specific areas of operational coordination, but additionally input would be anticipated from other areas of Internet activity. The area of support for the IEPG activity is an open issue, and further investigation of this is required by the co-chairs.
The co-chairs were tasked to develop this further and to report back to the IEPG on potential organisational structures for the IEPG within the Internet domain.