Seattle, Wa, U.S.A.
The following document is not structured as a comprehensive record 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 by the IEPG or by individual members of the group.
Geoff Huston
The group examined the charter under which the IEPG had operated in relation to the CCIRN, and considered it appropriate to revise this charter in three broad areas:
The IEPG drafted a document which reflected the purpose and general domain of activity of the group. The IEPG Charter is attached to these notes.
The group endorsed the role of co-chairs to be undertaken by Elise Gerich, Geoff Huston and Bernhard Stockman.
The group also noted that current IEPG support arrangements are voluntary and provided through the co-chairs, and as such these support levels will not readily scale to provide adequate support for significantly more intensive or broader concurrent areas of IEPG activity. It was noted that support structures will require further consideration in the event of growth in levels of activity of the IEPG.
The group noted that the charter will be passed to ISOC council for legal review concerning whether the wording of the charter is appropriate for the envisaged scale of activity undertaken within the domain of the IEPG. In this area of consideration of potential liability the group noted that clarity of the agenda topics was a crucial issue for future meetings.
The consideration of this item focussed on recent developments within Europe which were relevant to general infrastructure provision. It was noted that a number of EBONE participants are now becoming Dante clients and a number of trans-Atlantic links are being withdrawn from the EBONE environment to be recast as specific mission facilities. It is likely that EBONE will continue operation after July 1, with Renater (Fr) and NORDUNET (Se, No, Fu, Dk) providing much of the core support for a continuing EBONE program. The high capacity Trans-Atlantic links operated by EBONE are the Paris and Stockholm T1 links, while T1 links to the UK, CERN and Dante are operated independently.
Dante is now operational, providing a service based on the underlying EMPB infrastructure and the Europanet IP service. The Dante service provides European infrastructure, trans-Atlantic capacity, and is about to install a link to Korea.
The EBONE - Europanet IP interaction was discussed, and the operational objective was reiterated that under normal circumstances inter-European traffic will not transit non-European IP infrastructure.
A rough schematic of the Atlantic from a European perspective is as indicated below:
It is noted that general infrastructure Trans-Atlantic capacity is constrained , and congestion is occurring on a number of these links carrying general infrastructure traffic.
The increasing load of MAE-EAST is exacerbating the extended Ethernet architecture, and packet loss rates are now at peaks of 10 - 20% levels at this exchange (a combination of both real collisions and lost collisions due to ethernet segment length within the MFS configuration). Work is underway within the MAE-EAST subscribers to address this performance issue while preserving the essential characteristics of the layer 2 exchange architecture.
It was noted that the MAE-EAST Exchange ICMNET routers are now configured with 64M of memory, as 4Mb configured routers are now incapable of containing the full Internet route set in a defaultless mode.
The MAE-EAST exchange is now routing within a total routing configuration which contains the major part of the Internet, and route flaps are now causing some 30 - 50 route updates per second for the MAE-EAST routers. This concentrated level of route changes has required changes to route update processing software where hold-downs are used to defer route update processing to a regular interval.
While hold-downs are a temporary solution to the volume of routing updates attention to the generation of routing updates is a significant issue across the Internet. The route update level can be reduced substantially through suppression of route flaps, which in turn can be addressed by Internet service providers performing either static route anchoring, or using CIDR route advertisement as a means of route flap suppression. There is a also a requirement for more sophisticated route flap diagnostic tools within the Internet service domain. Merit's offnet tool was noted in this context.
The distributed nature of the problem of origin of route flaps was seen as a significant issue, and accordingly an IEPG Operational Advisory Note on Route Flapping has been drafted, for circulation throughout the operational domain.
A potential architecture for the extension of the MAE-EAST exchange into a geographically extended exchange point was outlined. It was noted that a Layer 2 tunnel across existing infrastructure which connected MAE-EAST to the Stockholm EBS is being considered as one possible extension mechanism, with route servers located at each exchange location. It was noted that further consideration of the issues of a Distributed Global Internet Exchange (D-GIX), and the deployment and use of route servers at such exchange points will take place, and it is anticipated that a document outlining the relevant issues would be included in the IEPG document area.
The group explored current routing vulnerabilities, noting that the use of BGP sessions key on the open session exchange only did allow the possibility of session capture by third parties, and the action of table flush on receipt of TCP Close / RST allowed the possibility of denial of service attacks on routing sessions.
An advisory note was prepared highlighting these vulnerabilities: IEPG Operational Advisory Note on Routing Vulnerabilities. (The matter was subsequently referred to the BGP WG of the IETF, who indicated that no further protocol development would be undertaken by the BGP WG, and that area of vulnerability was being addressed within the IDRP WG.)
Mark Kosters of the US Internic Registry Services presented information on the rwhois client and server. rwhois is a directory information retrieval tool which integrates the information structures of the whois, whois++, X.500, SMTP and DNS within a single client / server interaction model. The model of the rwhois information structure is a referral operator constructed within the protocol, allowing access to NIC information using a distributed model of authoritative information which mirrors delegation lines, and using a referral chain where referrals coincide with administrative delegation.
The initial client and server implementations have been tested by the INTERNIC, the RIPE NCC, APNIC and AUNIC, and the testing is now moving to a phase using a complete informational database and initial operational deployment.
rwhois effectively supports a delegated model of authoritative information, where the entity responsible for a particular delegation authority can locally maintain authoritative data describing the current state of the delegated domain. The model readily matches the current address allocation environment.
Discussion considered aspects of route registry maintenance, where it was noted that registration of routing elements and aggregate routing elements may not necessarily follow a single delegated hierarchy, and overlapping aggregates may be registered in different routing databases.
Current cooperative agreements relating to the operation of the NSFNET are anticipated to conclude in October 1994. In terms of NSF's future role within the Internet environment the single cooperative agreement is to be replaced by a set of agreements covering the operation of a very high speed backbone service (vBNS), Network Access Points (NAPs), the Routing Arbiter (RA) and the funded acquisition of network transit services by the Regional Network Service Providers. The existing International Connections Management program (ICMNET) is not directly effected by these changes, and will continue in place at present.
IEPG consideration of this architecture examined the potential roles of the NAPs and the transit Network Service Providers within the context of the Global Internet. infrastructure. The NAPs are a Layer 2 architecture where each connected entity can use inter-domain route peering to define interactions with any other NAP connected entity (1:1 bilateral agreement). Also any NAP connected entity can also gain a comprehensive view of local and remote reachability through peering with a NAP-attached Route Server operated by the RA agency.
It is envisaged that neither the Route Servers, nor the NAPs themselves will implement any Internet policy: policy is expressed in the route registry entries through preferred access paths and expressed at the NAP in terms of bilateral peering agreements. It is also noted that the NAPs are in themselves interconnected entities. Interconnectivity is provided as a NSP provided transit service, provided by any transit NSP. No explicit Layer 2 interconnection is envisaged in this architecture.
For international service providers the connection options within this architecture include direct NAP connection (and selection of an inter-NAP transit service provider), connection to a NAP-connected NSP (and implied NAP interconnection through the NSP), connection to a regional NSP, or, given an appropriate policy match, service via ICMNET (although connectivity arrangements within the NAP architecture are unspecified as yet for ICMNET clients).
The Routing Arbiter activity combines both routing registry functions and development of evolutionary routing technology. The interaction of the Route Server (an activity of the RA program) and the NAP clients as a service interaction is a current task, and static and dynamic RA service acquisition models have to be defined.
Very brief outlines of NAP provider's potential facilities were made to the IEPG by Sprint, Bellcore, Pacbell, MFS and Ameritech.
The Routing Registry proposed operational environment was also discussed, and the approach being proposed by Merit is one which is a compatible extension to the work already deployed by the RIPE NCC and the existing NSFNET PRDB operated by Merit.
Discussion included issues of aggregation management and PRDB queries for aggregate registry entries and queries.
It is intended to convene the next meting of the IEPG immediately preceding the December 1994 IETF meeting, as a one and one half day meeting.