July 1995 IEPG Meeting
Location: KTH, Stockholm, Sweden
Date: Sunday, 17 July 1995
Meeting Chair: Havard Eidnes
Minutes: Erik-Jan Bos
Participants:
Name Organization E-mail address
----------------------- -------------------- ---------------------------
Guy Almes ANS [email protected]
Tony Bates MCI [email protected]
Per Bilse EUnet [email protected]
Stan Bornski InterNIC [email protected]
Erik-Jan Bos SURFnet [email protected]
Scott Bradner IESG/Ops AD [email protected]
Al Broscius Bellcore [email protected]
Nevil Brownlee Tuia [email protected]
Joe Burrescia ESnet [email protected]
Randy Bush YMBK, Inc [email protected]
Brian Carpenter CERN [email protected]
David Conrad APNIC/IIJ [email protected]
Sean Doran Sprint [email protected]
Havard Eidnes NORDUnet [email protected]
Steve Feldman MFS Datanet [email protected]
Vince Fuller BBN Planet [email protected]
Elise Gerich Merit [email protected]
Frode Greisen UNI-C/Ebone [email protected]
Geert Jan de Groot RIPE NCC [email protected]
Phill Gross MCI [email protected]
Tony Hain ESnet [email protected]
Kim Hubbard InterNIC [email protected]
Jan-Olof Jemnemo Telia Integration [email protected]
Ola Johansson Unisource Sweden [email protected]
Marijke Kaat SURFnet [email protected]
Daniel Karrenberg RIPE NCC [email protected]
Akira Kato WIDE [email protected]
Sean Kennedy BBN Planet [email protected]
Mark Kosters InterNIC [email protected]
Eliot Lear SGI [email protected]
Peter Lothberg Stupi [email protected]
Kaori Maeda Hiroshima City Univ [email protected]
Eric Malmstroem Transpac Sweden [email protected]
Bill Manning ISI [email protected]
Keith Mitchell Pipex [email protected]
Pushpendra Mohta CERFnet [email protected]
Yoshiko O Chong Fong APNIC [email protected]
Yoshihiro Obata KDD [email protected]
Andrew Partan UUNET [email protected]
Michael Patton BBN (DISA) [email protected]
Marc Pichon Transpac/RAIN [email protected]
Jon Postel ISI [email protected]
Barry Raveendran Greene Singapore Telecom [email protected]
Yakov Rekhter Cisco [email protected]
Willem van der Scheun SARA [email protected]
Kazuya Shimada KDD [email protected]
Paul Vixie CIX [email protected]
Ruediger Volk Deutsche Telekom [email protected]
Wilfried Woeber VUCC/ACOnet [email protected]
1. Welcome
Havard Eidnes opens the meeting and welcomes everybody to KTH. Peter Lothberg (a little later) welcomes everybody to Stockholm, Sweden.
2. Note taker
Erik-Jan Bos volunteered to take the minutes.
3. Brief review of regional operations groups
NANOG
Elise Gerich reports on the status of the NANOG. NANOG is the North American Network Operators Group which meets three times a year. The meetings of NANOG are open.
EOF
Peter Lothberg reports on the European Operators Forum. People from Europe that are working on projects report on what they are doing. Items discussed:
- the building of a high-speed infrastructure (like vBNS)
- the building of new infrastructure (like TEN34)
- European Exchange Points
The next meeting of the EOF will be in the morning of October 11th, 1995
in Amsterdam (next to the RIPE NCC).
ZANOG
Bill Manning reports. The group just started up. ZANOG now is a mailing
list. The first items on the to-do list are:
- start a registry, like the RIPE NCC
- start one (or more) internet exchange points
Unfortunately nobody from ZANOG could be present. The ZANOG can be
reached at (please note the underscore).
APNIC
David Conrad reports on the Asia-Pacific region. There is no operators
forum in the AP-region yet. APRICOT is the name for a meeting that will
take place in Singapore, in January 1996. People from the IEPG are
welcome to attent the January meeting. There is a mailing list for more
information: .
4. Requirements for Traffic monitoring
Nevil Brownlee reports on the requirements for traffic monitoring. In
1990 an IETF Working Group (Internet Accounting) started the traffic
monitoring work. In the traffic monitoring model you find:
- Meters
- Collectors
- a Manager
The model looks at "traffic flows" and uses "rule files".
The relevant documents are:
- RFC1272
- draft: accounting architecture
- draft: accounting meter MIB
There is an implementation available, together with more information:
http://www.auckland.ac.nz/net/Accounting/ntm.Release.note
Currently, at least 20 sites are using NetraMet.
The concept of a Metering Exchange Point is explained: If you run an
exchange point you can have the problem of routers that have more than
one link connected to (e.g.) an FDDI ring. Bill Manning states that this
in not a real problem: The routers on the ring that have the link are
not part of the exchange point, the links are part of the network of the
router owners. There is nodding in the group.
Current proposed solutions:
- make your router vendor implement the Meter MIB
- make sure that each router has exactly one link
The next steps include:
- persuade router and switch vendors to implement the Meter MIB
- start an IETF WG to further develop the accounting model (proposed
name: Realtime Traffic Flow Measurement)
- looking for volunteers for:
- FDDI testing
- MIB implementors
- WG supporters
Scott Bradner asked those interested in supporting a working group to
send him an e-mail note saying so.
Peter Lothberg explains that (at least in Sweden) by law you are not
allowed to look at the traffic on the exchange points. Elise Gerich asks
how this one is different to nnstat (or others). An important thing is
that this implementation is classless. Another thing is that there can
be many meters and collectors distributed over many sites, and they do
not have to be synchronised with each other.
5. Update of post-current-ICM-contract connectivity
NSF has a contract with US Sprint for the International Connections
Management. Next April this contract runs out and the question now is:
what are the Europeans planning to do.
Peter Lothberg states that NSF wants three things on this:
- Production networking
- Very high speed networking
- Help starting-up countries
Currently there are 12 links where NSF pays at least a HC, other circuits
are paid by the countries themselves. Steve Goldstein presented a paper
at INET'95 on this subject.
Frode Greisen reports that there are many many lines between Europe and
the US. There is one "fat one" now (34M out of Stockholm) and more are
expected. NSF is seeking partners in Europe for more lines, however,
Steve Goldstein expects that NSF will draw out from this arena as well
in a few years time. Decisions for improvement in trans-Atlantic
capacity is expected in the next few months.
6. Update on European network situation
DANTE post-EMPB model -- representative from DANTE
Since there is no representative from DANTE present, this issue is
skipped.
Exchange points -- Erik-Jan Bos, Peter Lothberg
Erik-Jan Bos reports on the current situation in Amsterdam. The current
parties are connected to the Amsterdam Internet Exchange:
- RIPE NCC
- DANTE EuropaNET
- EUnet
- NLnet
- SURFnet
- Ebone
- broodjeham (multicast router)
Peter Lothberg reports on the current situation in Stockholm. There are
around 15 providers connected to the Stockholm Exchange. Two of them are
US operators.
Ten34 and impact on production infrastructure
Since there is no representative from DANTE present, this issue is
skipped.
7. Status of the FIXes in the US
Tony Hain reports that MCI is now connected to FIX-East. There are ideas
on moving FIX-East away from College Park, but there are no concrete
plans.
Keith Mitchel asks what the policy of the Feds-Nets is regarding peering
with non-US providers. The answer is that it is not different from
peering with US providers.
7.5 Asia-Pacific region Internet Exchange Points
(this item is put in as a bonus item, waiting for lunch, thanks David)
David Conrad reports that there are a few layer 2 interconnects in the
AP-region. Examples include:
- HKIX (Hong Kong Internet Exchange): ethernet exchange in Hong Kong,
where some 25 to 30 service providers are present.
- STIX (Singapore TelCo Internet Exchange): Interconnect for Vietnam and
many other countries in the region.
8. Charging models, settlements, costs. Political issues,
engineering impact.
Sean Doran explains that SprintLink sees a growth of 20% per month and
that US Sprint's competitors are seeing roughly the same. How do we keep
up with this growth? Some routers of SprintLink are running at
half-capacity (e.g. in terms of switching capacity). Within around 6
months there will be no boxes available to keep up with the growth.
Four areas are crucial:
- Technical:
- We need a box that can accomodate the growth for the years to come.
SprintLink talks to switch routers to develop a BFR (some say this
means "Big Fine Router", your mileage may vary).
- Line capacity is also a worry, experiments with IP-over-SONET are
taking place.
- Capacity at exchange points is a worry. The general feeling is
that the capacity of an exchange point should be an order of
magnitude faster than the incoming lines (multiple exchange points
often can imply asymmetry).
- Addressing: Comes back to CIDRD, basically. Exhaustion of the IP
address space is imminent, but how soon will this happen.
- Scaling: these issues are becoming tough.
- Training: NOCs sometimes are not up-to-skills. Training people is not
to be underestimated.
- Multi-homed: There is a tendency for customers of one provider to
become multi-homed through another provider.
- Knowledge:
- Knowing what is going on: There are a lot of people that are not
coming to meetings like the IEPG or read e-mail.
- Money:
- Vertical integration: Companies doing "everything" from running a
backbone to dial-in IP service. Some providers start as a backbone
provider and now have to do dial also. Or the other way around, a
provider that starts up as a dial-in provider.
- Politics:
- A lot of politics is coming in. This creates inefficiency. The
engineers, busy with the technology, have spent too less time
educating the politicians.
The real issue: How do we go by fixing this? People need to educate the
politicians to do the right thing. Some decisions have great political
implications but are hairy to implement.
Peter Lothberg explains how the phone companies do charging: Phone
company A and B want to interconnect and both buy a HC to each other. A
phonecall originating within a customer of A to a customer of B also
makes money flow in the direction from A to B. The conclusion on this
is that this is a great model for the connection-oriented world.
Sean Doran explains a model where there are different levels of service
provision:
- Dial-in providers: for end-user support
- Mid-level providers (regionals): for dial-in provider support and large
customer support
- International providers: support for the regionals
Sean states that international providers should not want to enter any of
the other levels (vertical approach), which more often than not means
competition to your customers. Tony Bates warns that this model may be
fine for SprintLink but not necessary for other companies. The model of
wholesalers and retailers works well in other industries.
Sean Doran promises to make a document out of all this.
The discussion leads to multi-homing. Why would an organization want to
be multi-homed? Possible carrots are:
- economics
- resilience (or reliability)
Two issues are brought up WRT multi-homing:
- what does multi-homing do to the address space
- what does it do for the routing
Often, one problem with multi-homing is explaining it to people. And
besides, there are different flavors of multi-homing.
9. Dual-homing in a CIDR block
Prologue: NAT boxes are not considered in this agenda item.
Yakov Rehkter addresses the issues of multi-homing in a CIDR block by
first explaining the issues:
- Use of AS number:
- Each multi-homed site should have its own AS number.
. The question is: Can "private" AS numbers be used?
- Each multi-homed site should use BGP to peer with its providers,
since this allows dynamic rerouting.
- There is a draft document: draft-ietf-idr-autosys-guide-03.txt
- One prefix - One origin AS:
- A given prefix can reside in only one AS. If you have aggregation this
can be violated (example: when a multi-homed site has address space
from one of his providers this provider will advertise the prefix of
the block from his AS; the other provider of the customer will
announce the prefix from the customers ASN).
- Each prefix has to have a unique origin.
- Aggregation (AS_SET) may create some confusion to this principle.
- Path preferences:
- Need the ability to influence upstream providers when multiple paths
are available
- Multiple interconnects with direct provider; one should be using
MEDs.
- Multiple paths to some indirect (upstream) provider, known as
"AS-stuffing".
- Need to have a mechanism to specify "destination preferences", two
Internet Drafts:
- draft-ietf-idr-bgp-dpa-01.txt
- draft-ietf-idr-bgp-dpa-application-01.txt
- There is an idea for a New BGP Attribute which works with the
existing route selection attributes such as MED and Local-Pref.
- Issues regarding Address Allocation:
- We need to look at the impact on aggregation.
- Multiple addresses (one per provider) which is very good for
scaling, but not practical today.
- Address from one of the providers:
- which provider to select?
- where the aggregation could occur?
The idea is: Get your address space from your least preferred
provider (so only your preferred provider needs to announce this
prefix, and for your "back-up provider" it falls into his CIDR
block).
- Provider independent address, this is however the worst case for
getting scaling issues right.
- Routing Information Aggregation:
- There is a growth in the number of multi-homed subscribers
- We need to explore possibilities of aggregation above the immediate
(direct) provider level:
- use of proxy aggregation (is it really "proxy"?)
- continental aggregation (is it practical?)
The feeling is that this is *not* practical.
- what is the role of Routing Registries?
Elise Gerich reports that in the RADB 436 prefixes have more than one
originating AS, which is around 1% of the registered prefixes.
Multiple addresses per interface could solve this. This is not a router
problem, but a host problem. A NAT-box might also be able to solve this
problem (but this was declared outside the scope of this talk).
10. Strategies for maintaining correct information in
routing registries
Elise Gerich reports that the RADB was populated from the PRDB. A
certain amount of information in the PRDB was obsolete however. By hand
this incorrect information was analyzed, e.g. by looking at the BGP
path. The RADB does not have any routes anymore that don't have an
origin.
Another problem in the RADB was that there were ASN listed in route
entries of networks that were no longer peering with AS690. This is
known as bogus advisories in the ASs. The IEPG recommends to get rid of
all the bogus entries (aka "clean-up the advisory").
Keith Mitchell askes what the "policy field" means. Elise promised to
look into this and to report back to the IEPG list. Tony Bates remarked
that "maintainers" can maintain this information by themselves (but of
course the purpose of this field needs to be clear first).
Some statistics: There are 565 maintainer objects currently in the
RADB. Slightly more than 100 do not have a real maintainer.
For Canadian and European information the RADB will rely on the RIPE
NCC and CA*net registries. With respect to the MCI RR the same will be
done. This is not fully implemented yet. The registries need to sit
together to see which route to prefix needs to be purged from which
data base. Currently the RIPE NCC data base, RADB and the MCI data base
are sync-ed each 24 hours.
Randy Bush askes for guidance where to register routes. Wilfried Woeber
suggests to have the submitters submit the entry just once, and have
"the system" flood it out to the other relevant data bases.
There are several aut-num:-objects with no as-in:- and as-out:-tags in
there. People are recommended to check their entries. The off-net tools
will be run again to do more sanity checking.
What to do with more specific routes for an aggregate. InternetMCI and
RIPE NCC keep these objects. The question is: Should we use the
route:-object as it was supposed to be used? Also here the maintainer is
the responsible person. A suggestion is made to automate flagging of
inconsistencies and mail them to the maintainers with a template to fix
and mail back.
The idea of aging route:-objects is slightly touched: Put a "Best
Before"-date on these objects.
David Conrad is a little concerned about the fact that anything gets
registered (about who is doing what to whom). There seems to be confusion
about the intent of the routing registry.
11. Status on what the Asia-Pacific region is doing for
a routing registry
APNIC hands out ASNs now. There are four route:-objects now, without any
policy information, in the APNIC routing registry. APNIC is into a
project with a Singapore agency right now to set up a routing registry.
David questions the need to have yet another routing registy. Daniel
Karrenberg responds that a properly maintained routing data base with
up-to-date information is good to have.
David reports that some countries are starting their own routing
registries. The suggestion is made to these countries that when they do
it, they have to make sure that they put in enough resources.
12. Update on the Class A address subnetting pilot
Geert Jan de Groot reports on the what, why and how of the 39-experiment.
This experiment is documented in RFC1797. Geert Jan's sheets can be found
on:
ftp://ftp.ripe.net/ripe/presentations/iepg-geertj-EXP39.ps.Z
The issue is that blocks of Cs were downwards compatible. Chuncks of As
could give problems.
There is a mailing list for this experiment: . Please use
-request for (un)subscribe requests.
Today there are 22 prefixes visible in the 39-experiment. Most prefixes
only have loopback interfaces. However there are a lot of machines in
the DNS for the upcoming IETF terminal room, both for the terminals as
well as for the laptops.
The host ftp.ripe.net was moved to 39.13.5.97 on 15 July 1995.
Cisco routers, under certain conditions, announce 39.0.0.0/8 if it learns
of a longer prefix in net39, one needs to look at:
- no auto-summary
- ip subnet zero
- Filter 39.0.0.0 0.255.255.255 in announcements
- ip classless
Classfull IGPs (like RIP and IGRP) are not to be used when chuncks of
class As are becoming used.
EuropaNET (EMPB) filtered "subnet" info, all subnets in a classfull way
were filtered. This is changed now, since EMPB Ops removed the filter
that specified that no subnet information was allowed.
What works for this experiment:
- Cisco
- BSD 4.4 running gated
- Telebit
- AIX running gated
- most end systems (using default routing)
There are three IP stacks in hosts that are classless:
Last week 41 reported okay and 2 were not okay, both in Japan. Randy Bush reports that from the terminal room ESnet destinations are not reachable.
13. RFC 1466bis -- Updated guidelines for management of the Ipv4 address space.
14 AoB
- Havard Eidnes asks whether this meeting was useful. The general feeling is yes. Regarding the issue of how often to meet the consensus is: twice a year, co-located with an IETF.
--- End of Minutes