APCCIRN-042

APCCIRN-042

1994.5.16

Minutes from the D-GIX meeting

Stockholm April 20, 1994

Bernhard Stockman

Participants

Peter Dawe <peter@pipex.net>

Havard Eidnes <Havard.Eidnes@runit.sintef.no>

Peter Lothberg <roll@stupi.se>

Petri Ojala <ojala@EU.net>

Bernhard Stockman <boss@ebone.net>

Sven Storgards <sven@upsys.se>

Olle Wallner <wallner@swip.net>

Lars-Johan Liman <liman@sunet.se>

Report on the US situation (Peter Lothberg)

At the Seattle IETF there were some informal meetings around the

D-GIX implementation with people from Europe, US and the Pacific.

The current MAE-East implementation of the GIX suffers from resource

limitation in so far that the current ethernet, distributed by MFS,

is severely overloaded. One possible solution is to move to an

etherbridge implementation. Another discused alternative is to

install SMDS.

Three primary NAP's have been awarded by NSF. PacBell on the West

Coast, Ameritech in the Chicago area and Sprint close to New York on

the East Coast. Looking to the coming NAP infrastructure a move of

the DC GIX to the New York NAP location would make it easy to

integrate domestic US infrastructure with transatlantic capacity.

It will be necessary to find a way to interconnect the West and East

Coast D-GIX connections. One possible way could be to agree on only

one location of the US D-GIX depending on the cost for extending

international connections from their current termination points when

needed.

On the West Cost transpacific lines mainly terminates at Stockton or

NASA Ames. Sprint will make capacity available between Washington

DC and New York (DS3) and between New York and Stockton (T1) for a

duration of around one year. NSI has agreed to allow installation of

capacity between NASA Ames and Stockton.

It was pointed out that it must be made clear to participating

organizations that the trans-US capacity will only be available for

around one year and after that, other solutions has to be found. All

together it should be possible to implement a distribution of the

GIX between the East and the West Coast.

A requirement on routers installed at D-GIX location is that they

have to cope with current routing load, that is, they must be able

to support full routing with the foreseen amounts of routes.

The D-GIX group decided to produce a technical document outlining

the D-GIX architecture (Peter Lothberg and Bernhard Stockman). This

draft paper will be distributed to the IEPG list for further

comments. A first draft version shall be ready no later than

beginning of May 1994.

D-GIX implementation

The implementation of the distribution of the GIX between Stockholm

and Paris has been delayed due to unforeseen technical problems.

The original intention was to use Cisco routers both providing

bridging and tunneling within the same router. This was currently

not supported by the Cisco router. According to knowledgeable

sources Cisco is working on this but not with highest priority

though.

There are some possible alternatives:

1) Await new version of the Cisco code

2) Install Vitalink bridges

3) Await the leased line that will be ordered

As both alternatives, 1) and 3), has no guarantees to happen in the

very near future the meeting decided to for an interim period of

time use alternative 2).

This implementation will initially be tested locally at KTH before

being deployed between Paris and Stockholm. Lars-Johan Liman will

take the responsibility for this test to be undertaken April 25 -

29.

It shall be pointed out that alternative 2) above uses Cisco routers

to encapsulate the HDLC traffic coming from a Vitalink into a tunnel

which can (and will) run over the existing IP infrastructure. Thus,

for an interim period, no real change of the physical infrastructure

has to be done, and the impact on the service provider is reduced.

It is not possible to extend the D-GIX implementation to Washington

DC due the traffic overload of the MAE-East ethernet. Such an

extension must thus await either the upgrade to the MAE-East

capacity or its movement to the New York NAP localities where

sufficient capacity should initially be installed for international

connections. Peter Lothberg will go to US May 9-13 and may be able

to report on the progress of the New York NAP during the RIPE

meeting the week after.

It was pointed out that the involved networks should be informed on

the usage of the lines and agree that such usage is viable and in

accordance with their policy before any change of underlying

technology is undertaken. Havard Eidnes will inform Peter

Villemoes.

Route Server status

The current D-GIX implementation does not contain a Route Server at

the moment. This is due to the fact that parts of the Route Server

and Routing Registry framework still has to be put in place.

The route server implementation could be seen has happening in two

phases:

- a "limited" route server, which merely collects all the routing

data, filters it on the basis of network numbers and redistributes

it as the "default local view" at a D-GIX location. There is

still need for a routing registry to make this work, but Gated is

capable of performing this task today. The purpose is to reduce

the n-squared peer problem.

- a "full-blown" route server which can take each connecting

provider's routing policy and present this view to this provider's

router on the local D-GIX point. This entails giving different

"views" of the routing tables to different peers, and Gated can't

support this today but work is on the way for a "multi-faceted"

route server providing such functionality.

It was mentioned it probably will not be at that many places where a

route server will be installed and by that this technology will not

be seen as having significant market advantages by commercial

enterprises. A consequence is then the development of this

technology should probably be undertaken by the academic community.

D-GIX consortium

The meeting discussed the possibility of a more formal body giving a

legal framework for the D-GIX service. The meeting agreed that such

a body was not necessary for the time being. If in the future there

should arise such a need it might be possible to join forces with

other organizations having a similar charter.

It was however pointed out the need for a technical operations forum

in Europe and that it was believed that EEPG may serve such a role.

As the formation of an EEPG in the current situation is dependent on

the proposed restructuring of RIPE it is today not fully clear what

the situation will look like in the near future.

The meeting agreed that an European Operators Forum (EOF) is needed

as a continuation of the work done within the Ebone Action Team

(EAT) and should not await internal RIPE issues before being formed.

A preparatory meeting will thus be held in conjunction with the

Vienna EAT meeting and a formal EOF meeting will be held in London

on June 22 1994. General D-GIX issues with respect to Europe will

be treated within the EOF framework.