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.