Draft minutes from 5th EOF meeting, January 25

[Havard Eidnes <]

Hi,

please find enclosed a draft copy of the minutes from the last
EOF meeting which was held in conjunction with the RIPE meeting
at the end of January.  I apologize for delaying so long in
sending the draft minutes out, to boot they have been ready for
far too long...

Comments/corrections, anyone?

- Håvard
							-*- Text -*-
=======================================================================
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT 
=======================================================================

European Operators Forum

Minutes of the 5th EOF Meeting				Havard Eidnes

Held at NIKHEF, Amsterdam, Wednesday 25 January 1995	NORDUnet/Uninett
							25 January 1995

------------------------------

Present:

Duncan Rogerson		ULCC/JANET		duncan@localhost
Kevin Hoadley		ULCC/JANET		kevin@localhost
Dmitry Avdeyev		MSU/Radio-MSU		ada@localhost
Frode Greisen		EBONE			frode.greisen@localhost
Lars-Johan Liman	EBONE NOC		liman@localhost
Havard Eidnes		NORDUnet/Uninett	havard.eidnes@localhost
Bernard Tuy		RENATER			bernard.tuy@localhost
Petr Kral		Cesnet			pkl@localhost
Oliver Doll		EUnet			od@localhost
Francis Dupont		INRIA			francis.dupont@localhost
Kim Hubbard		InterNIC		kimh@localhost
Mark Kosters		InterNIC		markk@localhost
Randy Conrad		APNIC			davidc@localhost
Graca Carvalho		RCCN			graca@localhost
Avgust Jauk		ARNES			jauk@localhost
Hakan Hansson		Unisource		hh@localhost
Andreas F. Schachtner	EUnet			afs@localhost
Per Bilse		EUnet			bilse@localhost
Stefan Biesbroeck	Belnet			stephan@localhost
Willem van der Scheun	SARA Network Services	sceun@localhost
Giovanni Armanino	GARR-NIS		armanino@localhost
Valeria Ross		CILEA			valeria@localhost
Antonio Blasco Bonito	GARR/CNR		bonito@localhost
Magnus Risberg		France Telecom		magnus@localhost
Hans Axen		France Telecom		haax@localhost
Eric Wassenaar		NIKHEF			e07@localhost
Keith Mitchell		PIPEX			keith@localhost
Luc Dierckx		INnet			luc@localhost
Wilfried Woeber		UniVie-ACOnet		woeber@localhost
Christian Panigl	UniVie-ACOnet		panigl@localhost
Zdenek Janout		CTU Prague-CESNET	janout@localhost
Vaclav Novak		CTU Prague-CESNET	novakv@localhost
Annie Renard		INRIA			annie.renard@localhost
Benoit Grange		INRIA			benoit.grange@localhost
Eugenie Staicut		RNC			estaicut@localhost
Franck Pradal		France Telecom		pradal@localhost
Christophe Chaillot	France Telecom		chaillot@localhost
Marc Pichon		Transpac/RAIN		pichon@localhost
Van Phuong Nguyen	Transpac/RAIN		nguyen@localhost
Jean Michel Planche	Oleane/PIPEX		jmp@localhost
Lukesz Ptoriejski	NASK			lukasz@localhost
Iveneusz Neska		NASK			irek@localhost
Joy Marino		ITnet			joy@localhost
Arnold Nipper		Xlink			nipper@localhost
Sabine Dolderer		DE-NIC			sabine@localhost
Andreas Knocke		DE-NIC			knocke@localhost
Willi Huber		SWITCH			huber@localhost
Thomas Stalder		SWITCH			noc@localhost
Paul Antonov		Demos/Relcom		apg@localhost
Michael Korotaev	Demos/Relcom		korotay@localhost
Peder Chr. Norgaard	Telebit Comm.		pcn@localhost

------------------------------


1.	Welcome

Being the host of the meeting, Rob Blokzijl welcomed everyone and
informed about the local logistics.


2.	Agenda Bashing

No changes to the agenda.


3.	Appointment of minute taker

Havard Eidnes was appointed minute taker.


4.	Apologies

No apologies received.


5.	Previous Minutes

Frode Greisen had a comment concerning a note in the minutes which
said "PL asked if this model could be extended to other common areas
in Internet networkservice provision." (referring to the agreement
concerning the operation of the London Internet Exchange (LINX)).

Some countries have formed consortia to take care of the funding
issues wrt. DNS registration, examples of Germany and Japan were
mentioned.  There was expressed interest in getting collected the
schemes used in the various countries - however, no volunteers stepped
forward to coordinate this.


6.	Status of European Interconnect Points

PL presented a matrix showing some of the different characteristics of
the Internet exchange points in Stockholm, Paris, CERN, London and
Amsterdam.  The characteristics were

 - IP address space used is part of D-GIX space?  Of the ones above,
   only Stockholm and Paris use this.

 - If it is possible to "bring your own box" to the exchange facility.
   Earlier CERN and Paris didn't have this -- they now have it as an
   option.

 - If the boxes on the exchange point is centrally managed or whether
   they could be managed by off-site personnel.  Also here, CERN and
   Paris only provided central management, whereas now they have this
   as an option.

 - All the exchange points mentioned above is fully operational.

 - Technology used.  Only Stockholm has FDDI as an option, all the
   other exchange points use Ethernet as the interconnect medium.

There was also mentioned several more exchange points which are
already in operation or are being set up, specific mention was made of
an exchange point in Denmark at UNI-C, one or two in Italy (one of
them using Frame Relay as the interconnect medium, thus the routers
connected to that exchange "point" are not co-located) and one in
Moscow in Russia where they plan on using FDDI.


7.	Report from IEPG meeting in December

At the 4th EOF meeting, Havard Eidnes was appointed to be the European
co-chair of the IEPG.  He attended the IEPG meeting in San Jose in
December and gave a short summary of the meeting:

 - Since the US Internet networking scene is ready for large changes,
   and some of the service providers (Sprint and MCI) presented status
   reports of their backbone planning and implementation.

 - The issue of settlements for peering was raised.  There was some
   discussion of where the delineation between what is "inside" and
   what is "outside" a provider's borders should be.  This also
   generated some discussion on the e-mail lists later where it was
   argued that settlements for peering would be unwise.

 - David Conrad of the APNIC raised the issue of charging for address
   space or leasing out address space to applicants, at a rate of
   approx. USD 0.10 per host address.  This is partly to fend off
   unreasonably large requests, but also partly to generate income for
   the APNIC to support it's activities.  If it were to be implemented
   it would generate pressures on other registries to do something
   similar.
   
 - PL commented tha the IEPG is becoming quie a large group, and this
   tends to slow progress and discussion.
   
 - There is talk of a MAE-West possibly to be implemented in NASA
   Ames' facilities.

 - Rumour had gotten around that there was going to be organized an
   International Internet Operator's Conference, initially planned for
   the end of February in San Diego.  This came as a surprise to a
   large subset of the audience at the IEPG meeting.  The IEPG had
   been invited to hold a meeting in conjunction to this conference,
   however since very little was known about the agenda for the
   conference it was decided that the next IEPG meeting would be held
   in conjunction with the summer IETF meeting being held in
   Stockholm.

   Frode Greisen commented that the conference has been rescheduled
   for April 11-12, still in San Diego.  There had not been agreed on
   any program yet for the conference.  A purpose of the conference
   would be to have a meeting in a little more formalized format with
   persentations, papers etc., and also to act as a common meeting
   ground for the various operators.  The ISOC (specifically Frode
   Greisen) is still open for suggestions on this conference.  A quick
   poll of the audience showed interest from maybe 1-2 persons on
   attending the conference.


8. 	Report on US changes and progress

Peter Lothberg presented a short summary, Elise Gerich filled in with
more details when she arrived concerning the ongoing changes of the US
Internet networking infrastructure.

The NSFnet-sponsored ANS backbone network will be removed at the
latest end of April 1995.  The major remaining providers are ANS, MCI
and Sprint.  At this time more than 50% of the US regional network
service providers have fully completed their transition away from
NSFnet.  Some of the large regional NSPs have moved to MCI
(e.g. BARRnet and NEARnet).

Of the NAPs (Internet Exchange points, so-called Network Access
Points) planned, only two are fully used for the exchange of
production traffic.  These are the Sprint NAP in NY and the de-facto
NAP operated by MFS, also known as MAE-East or MAE-East+.  The other
two planned NAPs (to be operated by Ameritech in Chicago, and PacBell
in California) do not yet carry production traffic, mainly due to
packet loss problems caused by problems with the ATM DXUs used in
those implementations.  Ameritech has declared that they will
implement a fallback solution based on co-location and FDDI should the
ATM-related problems remain unsolved.  This fallback is planned to be
ready by mid-february.  PacBell has not planned a fallback solution.

A question was raised about the federal network service providers such
as ESnet and NSI -- the background being that some of the european
academic service providers receive their US connectivity through usage
of links terminating in ESnet.  ESnet is perhaps the most pragmatic of
the federal networks, in that they are connected to MAE-East.  The
other federal networks are basically only connected to the FIXes.  EPG
explained that the federal networks tend not to sign blanket traffic
exchange agreements with other service providers, but more "pick and
choose" depending on who they have a misson-oriented interest in
exchanging traffic with.

At this point PL presented a schematic drawing showing the
interconnections between MCI, ANS, Sprint, ICM, ESnet, NSI and Milnet.
See ftp://xxx.xxx/xxx/xxx.idraw for a similar sketch.

The question of how to handle the CIX was also raised -- PL said that
the CIX is now more or less irrelevant -- as seen from Stockholm only
15 or 20 routes are only reachable through the CIX.

Wrt. the problems with the ATM NAPs PL shortly explained the problems
with the lack of buffer space on high-speed paths.  This is more fully
explained in a paper by Curtis Villamizar which is available from

	ftp://ftp.ans.net/pub/papers/tcp-performance.ps

There was also talk about a new exchange point being established on
the US west coast at the NASA Ames facility but open to any network
service providers, probably to be called MAE-West and to be based on
colocation of equipment.  So far this has not materialized.

Of special interest for the European networks, it was noted that the
ICM project in it's current form is scheduled to terminate at the end
of 1995, and that NSF eventually will be getting out of the buisness
of sponsoring network infrastructure.  Keith Mitchell quoted a rumour
stating that British Telecom through their partnership with MCI would
be installing a link to the London Internet Exchange and be willing to
carry traffic to and from MCI customers to the service providers at
the LINX -- the terms and conditions in connection with was unknown.

The issue of transit traffic from Europe to Asia was also mentioned.
Australia is going to become an MCI customer, so that is "not a
problem".  However, for other service providers connecting to a US
west coast Internet exchange point someone needs to subscribe to
transit service.

There is also a problem of how to finance high-speed trans-atlantic
links without giving some people free rides -- the cost of the
infrastructure has to be recoverd somehow.

Lastly, EG explained about the changes to the NACR process which is
planned.  The new infrastructure with the NAPs contain a function
called the "Routing Arbiter" (RA for short).  Part of this function is
to operate a routing registry which is going to be based on the
RIPE-181 model and software.  The old way of requesting connectivity
to the NSFnet (submitting NACRs) would be handled for approximately
two more weeks, and thereafter new submissions would have to use the
RIPE-181 syntax.  It was also the clear intention that e.g. european
service providers would only have to register their routes in one
place -- importation of data from the RIPE database was planned.  To
be able to do that would require a small addition to the RIPE-181
schema for the remaining period of the NSFnet transition, known as the
"advisory" attribute.  This proposal will be handled in the RIPE DB
working group.


9.	Intra European routing

PL reviewed a couple of possible network configurations for a regional
service provider showing the minimal requirements for their external
(and internal) routing.  Single-homed providers can use default
routing, multi-homed providers can in some cases cope with a
"mostly-default" configuration.  However, if the neighbour not on the
default path announces classless routes, the need for BGP-4 routing
arises.

As for configurations for default routing, PL recommended that a
default route be propagated by the up-stream neighbours with BGP
instead of relying on a "default network".  The reasons are several,
quicker convergence being one of them, the removal of the need to pick
a network to point default at, etc.  However, default routing still
has it's problems if there are other problems "downstream" from the
place injecting a default route or a default network, and to be fully
safe against such problems there really is no other alternative than
to run with full routing.  This costs more money (more expensive
equipment) but is easier to maintain (less man-time).

PL also pointed to a currently severe problem in the Internet which at
this time is not routing table size (most people who need it have
installed 64MB routers by now).  The current major problem is the
amount of routing updates occurring on the Internet, most of these can
be characterized as "route flaps".  This is causing the processors in
the routers to overload, with lacking responsiveness to routing
updates and general poor performance as a result.  There are two ways
to correct this problem:

 - Go after the service providers producing the most routing updates
   and telling them this is counter-productive.

 - Fully deploy CIDR, as this tends to reduce the number of routing
   updates (if only a component of an aggregate becomes unreachable,
   no routing update is sent).

Both of these avenues are being persued.  There was some discussion
about the dissemination of "flap reports" and that something needs to
be done to better make the "troublemakers" aware of that they are
causing problems.  And again, we were reminded that CIDR deployment is
too slow and that those who have not CIDRized their announcements
should go back home and do so.

Some concerns were raised over whether the many new small service
providers are aware of their duties in this regard, and that they may
contribute substantially to the lack of CIDRization and the increase
in the route flaps.  After some discussion it was decided that it
would probably be a good idea to invite some of the new players to a
workshop prior to the next RIPE meeting.  However, questions were
raised whether we would meet the intended audience (e.g. whether they
could afford to travel) with such an initiative.  It was also pointed
to the indirect service providers as a natural place for receiving the
required guidance.

	
10.	Global routing
		
An example showing the current inoptimal and asymmetric traffic
patterns involving 5 service providers was given as an example of the
amount of coordination which is required to fix routing problems.  It
was pointed to that more or less "global" adoption of RIPE-181 could
be a possibility, however, in the given example two of the service
providers did not belong to the RIPE community and hence have not
(yet) started using RIPE-181.


11. 	NOC interaction

The problem here is among other things how to "route" trouble tickets
and to ensure reliable handoff of responsibility for fixing problems.
This problem also partly points to the maintenance (or lack thereof)
of contact person information in e.g. the RIPE database.

It was also pointed out that one should define the expected minimum
responsibilities of new Internet service providers, such as "you need
to know X" and "you need a NIC and NOC function" etc.  The similarity
to the GISD work was pointed out, however what seems to be required is
a one-page summary which will be read and which points to other
documents for further information.


12.	Aggregation of non Euroopean address blocks

It has been a desire from certain corners to do "aggregation on a
grand scale", e.g. on the border to the US aggregate all the european
routes into e.g. 193.0.0.0/8 and 194.0.0.0/8.  This is of course not
without it's problems, and whether this is really practically feasible
remains to be seen.  There is however a concern that new (and
sometimes old) service providers are registering large blocks of
consecutive class C network numbers for inclusion in the NSFnet
routing -- these should instead be handled via CIDR.

At the meeting noone raised any major objections to the plan of doing
this "grand-scale" aggregation.


13.	Impartial CERT coordination in Europe

Little time remained to handle this issue.  Frode Greisen presented
the TERENA view which basically was that CERT coordination in Europe
maybe was not ready as a "service", and therefore could be handled as
a pilot project under the auspices of TERENA.  However, this issue is
still undecided within TERENA.

The EOF opinion on the issue was sought, noone raised their voices at
this point.  The issue was postponed for the next meeting. 


14.	AOB

None.


15. 	Next meeting.

Possibly mid-april at KTH in Stockholm

Next "plenary" meeting in conjunction with the RIPE meeting in Rome in
the beginning of May.