APCCIRN-018

APCCIRN-018

1993.02.03

IEPG

MINUTES OF IEPG MEETING

held at

Quality on Capitol, Washington DC

0930, Sunday 15 Nov 92

The fifth meeting of the IEPG was called to order at 9:30 am by

Bernhard Stockman; co-chair Elise Gerich arrived shortly after. As

well as IEPG members, representatives of network providers had been

invited to the meeting. Attending were:

George Abe Infonet abe@infonet.com

Vikas Aggarawal JVNCnet vikas@jvnc.net

Guy Almes FARnet almes@ans.net

Tony Bates ULCC t.bates@noc.ulcc.ac.uk

Nevil Brownlee Tuia nevil@aukuni.ac.nz

Brian Carpenter CERN brian@dxcern.cern.ch

Bob Collett SPRINT rcollett@icp.net

John Curran NEARnet jcurran@nic.near.net

Peter Dawe PIPEX peter@pipex.co.uk

Peter Ford LANL peter@lanl.gov

Gopi Garge ERnet-India gopi@ece.iisc.ernet.in

Elise Gerich Merit/NSFnet epg@merit.edu

Masayoshi Gohara NACSIS/SINET mg@sinet.ad.jp

Tony Hain ESnet/LLNL hain@es.net

Juha Heinanen Telecom Finland jh@datanet.tele.fi

Daniel Karrenberg RIPE NCC karrenberg@ripe.net

Jong Yeol Kim Korea Telecom kimjy@ring.kotel.co.kr

Peter Lothberg EBONE NOC roll@stupi.se

Jun Matsukata ISAS, NACSIS/SINET jm@eng.isas.ac.jp

Jun Murai Wide Project/Japan jun@wide.ad.jp

Andrew Partan UUNET asp@uunet.uu.net

William L. Schrader PSI wls@psi.com

Erik Sherk SURAnet sherk@sura.net

Brian Shiflett SPRINT brian@icp.net

Joo Y. Song HANA jysong@ring.kotel.co.kr

Bernhard Stockman EBONE boss@ebone.net

Fumio Teraoko SonyCSL/Wide tera@csl.sony.co.jp

Marten Terpstra RIPE NCC marten@ripe.net

Claudio Topolcic CNRI/FEPG topolcic@cnri.reston.va.us

Jack Waters SURAnet waters@sura.net

Wengyik Yeong PSI yeong@psi.com

1. GIX Discussion with Invited Guests

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

Bernhard introduced this topic by calling attention to two

documents:

* Draft Proposal for Global Internet Connectivity; IEPG Working

Document Guy Almes, Peter Ford and Peter Lothberg; June 92

* Internet Routing in a Multi Provider, Multi Path Open Environment

Tony Bates, Daniel Karrenberg, Peter Lothberg, Bernhard Stockman

and Marten Terpstra; 12 Nov 92.

The first explains the GIX concept and is recommended reading. The

second proposes a pilot GIX implementation, to be running by 15 Mar

92.

1.1 The GIX Pilot Proposal

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

Peter Lothberg reviewed the pilot proposal. The aim is to have a

LAN here in Washington to which all network providers can connect.

They will register their routes in a database which will be used to

maintain a Route Server on the LAN; the database will not be tied to

any particular policy. The Route Server will receive route

announcements for all networks and filter them using the database.

In addition individual nets may pair across the LAN, which allows

for exceptions to the general scheme.

Daniel Karrenberg provided further explanation, pointing out that

the aim of the proposal is to make sure that the Route Server has a

consistent view of routes into Europe, which it can distribute back

to any router it chooses to. In time we should implement similar

Route Servers for the North America and Asia/Pacific regions.

There was considerable discussion, which brought out the following

points:

* All network providers have to connect to the GIX. In this way

there is no connection hierarchy (which could impose routing

policy).

* The GIX concept does not depend on the choice of LAN medium. A

wide-area ethernet is proposed for the pilot simply because it is

readily available now. A point-to-point network connecting

routers in various parts of the world may be a better way sometime

in the future.

* The RIPE NCC has an effort underway to collect all the necessary

routing information and store it in their database for European

networks. This is expected to be sufficient for the pilot, but

the other regions will have to set up their own Route Servers.

The Route Servers will have to interact to provide each other with

stable routes between regions.

Overall it was AGREED that the pilot implementation was well

worthwhile, and should proceed with all possible speed so as to be

able to report results to the March 93 IETF meeting. The U.S.

network providers will help by providing the RIPE NCC with data

about routes to their networks.

1.2 The Washington Proto-GIX Implementation

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

Andrew Partan from UUNET made a presentation about PSI, Alternet and

Sprintlink's Metropolitan Area Ethernet (MAE) implementation using

MFS's 10 Mbps Ethernet in the Washington area - also known as

MAE-East. MFS provides each connected site with an ethernet AUI

cable connection; to the sites the system appears to be an ethernet

LAN. Each network provider will attach a router to the LAN; n**2

routing is used between the routers. All network providers are

welcome to join the MAE-East.

MAE-East appears to be a very good place to put the pilot route

server for the European networks. A lively discussion ensued,

covering the technical details of the MFS service, and especially

the implementation and location of the pilot route server. Among

the points of interest were:

* The LAN is a broadcast medium. It could be hard to determine the

source of bad packets appearing on it. In the long term someone

will have to provide proper operations support. Short term the

proposal should include procedures for handling faults.

* The CIX group supports the MAE-East project, but doesn't want to

influence it directly.

* By next year MFS should be able to provide connections at speeds

higher than 10 Mbps. Other communications suppliers have products

similar to MFS.

* We need to think about a funding model for the GIX. Long term a

distributed interconnection may well be a better way to connect

routers to the GIX, since it minimizes the connection cost for

each network provider. Short term the Washington MAE is the

simplest way of providing connectivity to the route server; it is

therefore the best choice for this pilot project.

* The MAE can provide traffic capacity between providers. All

routers must use the route server as their 'general case' source

of routing information. Pairs of networks needing greater traffic

capacity may, however, make direct interconnects between

themselves, and use 'special case' route entries accordingly.

Overall it was AGREED that the route server should greatly improve

the stability of routing between Europe and North America.

Questions of scaling - for example the handling of interactions

between two or three route servers - will eventually have to be

answered, but it is sensible to proceed with the pilot route server

as quickly as possible so as to gather experience with it and to

discover how it can be generalized.

Action items:

* The RIPE NCC has been collecting routing information as part of

their network database for some time. This will be sufficient for

the European route server; the main thrust of this development

will come from there.

* A North American route database - or better, a North American

route server - is needed too. Merit has a pilot project in this

area.

* Support is also needed from European providers. Daniel will pass

a RIPE document requesting route information to them next month.

* The prototype route server will be located on the Washington MAE,

which will be used as a testbed for the GIX / Route Server pilot.

A Unix system is needed there to run the route server.

* Involvement in the project by US network providers is needed, so

as to help sort out any North America - Europe interaction

problems as they occur.

* The proposal document

(Bates/Karrenberg/Lothberg/Stockman/Terpstra) will be revised.

Tony Bates will put it into an ftp server, and advertise its

whereabouts to the RIPE mailing list. Elise will copy this

advertisment to the IEPG mailing list.

The meeting adjourned for lunch at 1230.

After lunch the meeting resumed (without the invited guests) at

1408. Those present were:

Guy Almes FARnet almes@ans.net

Tony Bates ULCC t.bates@noc.ulcc.ac.uk

Nevil Brownlee Tuia nevil@aukuni.ac.nz

Brian Carpenter CERN brian@dxcern.cern.ch

Peter Dawe PIPEX peter@pipex.co.uk

Gopi Garge ERnet-India gopi@ece.iisc.ernet.in

Elise Gerich Merit/NSFnet epg@merit.edu

Masayoshi Gohara NACSIS/SINET mg@sinet.ad.jp

Tony Hain ESnet/LLNL hain@es.net

Daniel Karrenberg RIPE NCC karrenberg@ripe.net

Peter Lothberg EBONE NOC roll@stupi.se

Jun Matsukata ISAS, NACSIS/SINET jm@eng.isas.ac.jp

Jun Murai Wide Project/Japan jun@wide.ad.jp

Joo Y. Song HANA jysong@ring.kotel.co.kr

Bernhard Stockman EBONE boss@ebone.net

Fumio Teraoko SonyCSL/Wide tera@csl.sony.co.jp

Marten Terpstra RIPE NCC marten@ripe.net

Claudio Topolcic CNRI/FEPG topolcic@cnri.reston.va.us

2. Presentation on ERnet

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

Gopi Garge (Indian Institute of Science, Bangalore) gave a

presentation on ERnet, India's Education and Research Network. This

began in 1985 with dial-up slow-speed lines and is now running using

higher-speed leased lines, including a 64kbps leased line from

Bombay to Alternet.

Other networks in India are

INET - the public X.25 network

SOFTNET - run by the Department of Electronics; a commercial IP

provider

INDONET - run by the Computer Maintenance Corporation; a closed

network for IBM users

NICNET - a government network run by the National Information

Center

The next phase of ERnet's development is a VSAT network linking

eight sites into a star X.25 network running at 9600 bps. ERnet is

promoting the use of OSI protocols across Asia; to this end they aim

to consolidate Internet and OSI services by 15 Jun 93. Future plans

include a country-wide high-speed backbone for data networking.

Comments from the meeting centered on the use of VSAT for a small IP

network, which doesn't seem to have been done elsewhere. If this

works well it could be a useful model for other countries such as

Eastern Europe, South America. The OSI emphasis is also interesting

since we don't really have a lot of ISO implementation experience.

3. IP Addressing Issues

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

RFC 1366, Guidelines for Management of IP Address Space, was

discussed: no changes were suggested.

RFC 1367, Schedule for IP Address Space Guidelines, was considered.

Claudio explained that the proposed timetable was based on the

realization that address aggregation will be possible by mid-'93.

After some discussion it was AGREED that the timetable is

reasonable. All IEPG members are requested to put pressure on their

router suppliers to deliver reliable BGP4 implementations before 6

June 93.

Daniel presented a short report on the RIPE NCC. RIPE is supported

by all the European IP services providers; it's NCC has a staff of

three in Amsterdam, and has been functioning as an IP Address

registry (including registering route information) for four months

now. Overall the contacts between NCC and the providers has proved

very beneficial.

The NCC have already established local registries with service

providers in order to assign class C network numbers hierarchically

and thus suitable for aggregation. In this respect Europe has

already reached stage 3 of the schedule (RFC1367). This makes it

especially critical for Europe that the CIDR aggregation mechanisms

be available on time.

When allocating Class B addresses they are a lot stricter than the

RFC implies! They have assigned about 50 Class B addresses in the

last four months (including 19 to the Deutsche Bundespost); in each

case the applicants had submitted clear engineering plans

demonstrating their needs. Detailed information about this can be

obtained from the RIPE NCC quarterly reports available on

ftp.ripe.net. The most recent one (document ripe-73) gives a

detailed overview of local registries and network number

assignments.

Daniel commented that it would be helpful to set aside some

addresses for networks which will never be connected. A small

number of these could be used by many networks. Peter Dawe

suggested we should recommend setting aside some Class C addresses

now for this purpose. There was general agreement that this is

useful and Daniel offered to author an RFC about the subject

together with those not afraid to have their name associated with

such an inelegant thing.

Bernhard asked whether he should inform the BGP Deployment Working

Group that the IEPG supports BGP deployment as per RFC 1367. It was

AGREED that he should.

4. Review of the IEPG Workplan

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

The IEPG workplan was reviewed, and the items in it classified into

two categories: (T) for items which remain as high-priority ones,

and (B) for items which are being worked on by other groups, and

which are therefore low-priority items for the IEPG. The resulting

lists are:

(T) items

---------

1. Infrastructure

1.1 Global routing

1.2 Global DNS (there is a BOF at IETF)

1.3 Global address and route registration

1.4 Operational Impact of IP Transitions <== new item

2. Operations

2.3 Statistics and Measurement

6. Scaling and Forecasting <== new item

(B) items

---------

2. Operations

2.1, 2.2 NOC & NIC Coordination

3. Applications and Services

4. Multiprotocol Integration

5. Enhanced Network Infrastructure

During the workplan discussion two new (T) items were added.

'Operational Impact of IP Transitions' was put forward by Peter

Ford, who felt that the IEPG should generate input for ORAD to make

its members aware of any problems we could see arising from any IP

transition scheme which might be considered.

The second new item, 'Scaling and Forecasting,' was suggested by

Peter Dawe and supported by Daniel. It would be worthwhile getting

the CCIRN to fund someone to survey the network providers, asking

for their predictions as to the number of networks and routes they

have, and expect to have in a year. If done on an annual basis this

would provide valuable input for global network planning.

5. IEPG Current Status and Framework

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

Following recent discussions on the iepg mailing list (triggered by

a recent note from Hans-Werner Braun) it was decided to consider

whether changes in the way the IEPG is structured would be

worthwhile. The main topic of concern here was the rapid increase

in the number of 'general,' i.e. non-R&D network providers. It was

felt that by not having general providers represented on the IEPG we

are reducing our ability to support 'ubiquitous connectivity.'

Possible changes could be:

* Create a new ad hoc organization including existing IEPG members

and others.

* Notify the CCIRN that IEPG membership should be widened to

include representatives of general network providers.

After considerable discussion the meeting AGREED to request Elise,

Bernhard and Geoff to write to CCIRN informing them that "it is the

intent of IEPG to increase its membership." It was also AGREED that

the IEPG co-chairs would make the decisions as to which

organizations should be invited.

6. Action List for the GIX Proposal

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

The following actions were agreed upon:

* Peter Lothberg, Peter Ford and Guy Almes will finish their GIX

Proposal paper. They will publish this (as an Informational RFC?)

and say that the pilot project is proceeding, and that there are

lots of aspects of the proposal which need further work..

* Tony Bates, Peter Lothberg, Daniel Karrenberg et al. will publish

their paper as a 'rough draft,' and commence work on the route

server.

There being no further business, the meeting finished at about 1750.

Minutes taken by Nevil Brownlee.