DRAFT Version 2
RIPE 31 Edinburgh, 23, 24 and 25
September 1998 Plenary Session
Chair: Rob Blokzijl Scribe: Mirjam Kuehne/Naomi de Bruyn
1. Opening
2. Agenda
3. Minutes RIPE 30
4. From the Chair (Rob Blokzijl)
5. Report from the RIPE NCC (Mirjam Kuehne)
6. RIPE NCC 1999 Activity Plan (Daniel Karrenberg)
7. RIPE NCC 1998 Annual general Meeting (Keith Mitchell)
8. Some aspects of the new IANA (Dave Crocker)
9. New IANA: Progress reports (RIPE, RIPE NCC, CENTR)
10. European CERT Activities (Brian Gilmore)
11. Merit Post Routing Arbiter Activities (Gerald Winters)
12. Reports from the Working Groups
13. Next meetings
14. AOB
15. Close
-------------------------------------------------------------------------------
- 1. - Opening
Rob Blokzijl opened the plenary session of the 31st RIPE
meeting.
- 2. - Agenda
The agenda was approved as advertised. These minutes follow the
agenda.
- 3. - Minutes RIPE 30
The minutes of RIPE 30 were approved as they had been circulated
before the meeting. No comments/additions.
- 4. - From the chair
Rob Blokzijl thanked the organization.
- 5. - Report from the RIPE NCC (Mirjam Kuehne)
http://www.ripe.net/ripe/meetings/ripe-31/presentations/ncc-report/index.html
Q: When will the RIPE NCC report on Y2 compliance A: Maldwyn
Morris: we start testing after RIPE 31 meeting in a couple of
weeks time. As soon as we know what to do we will put a report
on the web.
Q: It might be useful to have more info on query statistics,
not only how much but also on domain and Inetnums etc. also
where domain would be delegated, whether change would be
accepted or not. A: Daniel Karrenberg (Dfk): we will work
on something.
Q: Pgp authentication. Last meeting NCC said we had license
for pgp. A: Joao Damas: we are finishing procedures, we'll be
reviewing them and let everyone know. You will need to have a
mntner object, you have to request that. It will check if you
actually have a mntner object, we'll register it when we
actually get the license. Details will be published in a few
weeks.
Q: did the NCC get much comments about problems with net66
allocations? A: Mirjam Kuehne: we have not had much
feedback lately, in the beginning we constantly talked to
people. Are frequently seeing customers with fire-walls get
on-authorized requests.
* Routing group discussion: signal queries versus Dfk we are doing
that. Will not show.
- 6. - RIPE NCC 1999 Activities and expenditure (Daniel Karrenberg)
Q: what about using the web for payments? A: Dfk: we do have
membership payments by credit card. People are reminded that
this is not prefered, preferably by bank. It could be a way
to improve no-payments of regular fees and meeting fees.
Do people want the ncc to get a secure webserver? Hear a lot
of yes. Pgp could be a potential solution? Maldwyn Morris
will put the ripe-141 request form on web, we want to also use
pgp for that, so the two might come together. Dfk: we will
look into various things.
Q: Procedure for re-allocating address space. A: Dfk we have
a procedure at the moment, taking space away is not the prime
objective. During some stage we look at whether there are
announcements. This usually does not result in taking space
away, can't do anything about the routing other then talking
to the upstreams. At the very end of the procedure might take
away inaddr.
Not as effective as taking away routing but will
work. Haven't reached those stages yet. As a first step
take we do not take the already assigned address
space. Only the space that was not assigned yet, we will
formally take back. We don't want to hurt the users.
Q: RIPE NCC gives address space to a LIR but if that LIR then
assigns that address space to a 'user' we must try not to
hurt that user. Hard to see the business part in that,
trying to understand the explanation. A: Dfk: we don't
lease. We have allocations and assignments. In our
registration procedures there is a formal step, we give
allocations. But nobody but a LIR can give
assignments. They cannot allocate. The assignments hold and
the allocation is taken back.
- 7. - RIPE NCC 1998 Annual General Meeting (Keith Mitchell)
Keith asked contributors present to please attend the AGM,
which will take place at Amsterdam Schiphol Hilton.
Discussed will be the fact that we need to make sure we have
one AGM meeting a year instead of 2. Furthermore we plan to
discuss the budget and the fees that come out of that budget.
Important also is the election of candidates/board members.
- 8. - EUROCERT. European Incident Response coordination service.
(Brian Gilmore. Vice president of technical programme of
TERENA)
http://www.ripe.net/ripe/meetings/ripe-31/pres/euro-cert/index.html
Q: What is the level of contribution you would expect of an
ISP A: 10.000 ECU as a sign-up fee. Terena expects to hand
over this to someone else. A hot topic currently for
discussion is to where it should go, to Dante? Or Ukerna (?)
This will be discussed during contributors committee meeting
next week.
- 9. - Merit Post Routing Arbiter Activities (Gerald Winters)
'Post-Routing Arbiter Merit Activities' Gerald Winters, Graig
Labovitz Merit network Inc.
http://www.ripe.net/ripe/meetings/ripe-31/pres/merit/index.html
- 10. - Some aspects of the new IANA (Dave Crocker) Level 10 Routing
Long Division and Irrational Factions
http://www.ripe.net/ripe/meetings/ripe-31/pres/level-10-routing/index.html
Dave Crocker gave some history about technical and managerial
issues that led to the current debate about the IANA.
NSF made the initial mistake to hand over a revenue stream to
NSI, of course NSI is now trying hard to keep it, and others
try to get a part of the pie.
Authority was given to IANA by the community, funding was
given by the US government. The US government funding should
have stoped earlier and taken over by the community. The
discussion started by the US government by their green paper
de-stabelised the Internet administration.
He then described the process of the ad hoc committee that
was set up to built new gTLDs. Also here, a few mistakes were
made, even though many good principles were in the structure
(not-for profit registries, independent oversight committees
etc.).
After that work had been done, it has been discovered that
the world had changed. There were constructive discussions in
the technical community. But there were also new players that
had never heard of the Internet before but had much influence
in the White House and that wanted to have a part of the pie.
Which mistakes were made in this process: - technical
community ended up in political discussions, where they were
only used to hold technical debates.
People who could not build the Internet, were trying to take
it over.
Dave Crockers says: we like to say "We are only
technicians, not politicians" But in fact we created a
social order, globally, that works for this type of technical
activities. It is now under social threat.
We do have influence and we should use it (difference between
the green and the white paper shows that this works). The
current set of bylaws (version 4) guarantee that no useful
activity can happen for the next years, it is much too
complicated to be implemented.
The community can change things, but not with being polite!
- 11. - New IANA: Progress reports (RIPE, RIPE NCC, CENTR)
Keith Mitchell (chairman of RIPE NCC board) He has been very
disappointed about the process and about the many
unconstructive people involved in discussion, without taking
the fact into account that we have a deadline to meet.
He also critises the IFWP process (attended two of their
meetings), main issues were domain name issues. Address issues
were put aside (being ignored)
Critises that wrap-up meeting was closed, this was then not
going to happen and took place anyway. Then the NSI and IANA
joined set of bylaws came out under strange circumstances.
Points out a few details of the current draft (can be found on
NCC reaction, see www.ripe.net/news/). In particular the focus
on a membership organisation; user community is represented in
too many places compared to other technical representation
(through at large board members and through individual
membership in the supporting organisations).
What can we do: 1. common statement from this community
(including various groups) 2. put names forward for the at
large board members other than that he is worried that the
whole process will be run by US government.
Randy Bush added one correction: there was not only discussion
between NSI and IANA, but also between NSI and US government.
And another possibility of influencing the procedure is to
involve the European Commission.
Niall O'Reilly as the representative of the CENTR group added
to that that also CENTR has sent out a reaction to the current
set of IANA bylaws. This covered most of the facts that were
also mentioned in the RIPE NCC reaction.
Daniel Karrenberg adds to the discussion that he received a
mail from Jon Postel who said that the IANA received the
reactions from this community and listend to them. They are
currently working very hard to put out a new version very
soon.
Hans Peter Holen asks if one possibility would be to dicuss
here or in a small group concrete suggestions for
changes. Come and speak to him any time, RIPE NCC is
coordinating it.
Frode Greisen suggests that the RIPE community brings out a
resolution that says that the IANA should go back to version 3
of the bylaws.
Q: Did the US government discuss the issue with other
governments? Dfk: knows that they are discussing certainly
with the EC and also with other governments.
Keith Mitchell supports Frode Greisens suggestions. Send out
statement 'go back to version 3, it wasn't broken, don't fix
it.'
Randy Bush supports the idea and suggests that RIPE together
with the RIPE NCC and CENTR produces this statement, this
would make it stronger. This idea was supported by the
participants.
- 12. - Reports from the Working Groups
Database WG ----------- Chair: Wilfried Woeber Scribe:
Ambrose Magee Participants: 50
EIX WG ------ Chair: Keith Mitchell <[email protected]>
Scribe: Kevin Hoadley
Purpose
Keith briefed the meeting on the purpose of the group, which
is primarily to disseminate information about the existing of
exchange points within Europe, particularly given that many
of the IXPs are run on a non-profit basis and thus do not
necessarily market themselves. Unlike most RIPE working
group, the EIX has no formal deliverables beyond this.
The mailing list for the group can be found at
[email protected]
AMS-IX - Amsterdam Exchange (Rob Blokzijl)
http://www.ams-ix.net
Two host organisations (SARA and NIKHEF), although both in
same building. Now have fibres into the facility from almost
all local suppliers, all with dual entry for
resilience. Exchange uses two Cat 5000s, interconnected by
gigabit ether over private fibre. 40 connected networks, 24
of which are international;6 more organisations currently
negotiating connection.
38.5 Tbytes traffic August 1998. Incorporated as a membership
organisation under Dutch law. Experimenting with multicast
traffic across the exchange, for more details contact Erik
Jan Bos at SURFnet. Open to all.
CIXP - CERN Internet eXchange Point (Jiri Navratil)
http://wwwcs.cern.ch/public/services/cixp/index.html
Started early 1996, though in practice had been a de facto
exchange point before this. Three telco providers available
to the facility. 15 ISPs currently connected to a Cat 2820,
with FDDI and switched ethernet and fast
ethernet. Installation 3K Swiss Fr, membership 1.5K Swiss
Fr/month.
Stockholm D-GIX (Lars-Johan Liman)
http://www.sunet.se/kthnoc/Services/dgix.html
No recent changes to the technology used. Located at several
commercial premises plus KTH. Though KTH had been trying to
discourage people from connecting there, this has not
succeeded, thus KTH will continue to offer router housing
(however no server co-location and no customer connections).
Have established a multicast exchange in Stockholm, using a
separate FDDI ring at KTH.
Currently establishing a second interconnect in
Gothenburg. Designed primarily for resilience for local ISPs;
policy regarding connections from foreign ISPs still to be
decided.
Comment that the distributed model in Stockholm was partly
enabled by the low cost of dark fibre within the city, which
is not the case in Gothenburg.
LINX - London Internet eXchange (Paul Thornton)
http://www.linx.net http://www2.linx.net engineering server
(traffic stats)
LINX now has 53 members. The joining and membership rules
have just been relaxed, by removing the requirement that
members have independant international transit, and by
reducing the minimum peering requirement so that members need
only peer with one other member. Expanding to second site in
Docklands, 3km from the existing site (with dark fibre and
gigabit ethernet between the two locations). Existing
hardware consists of multiple Catalyst switches and Plaintree
FDDI switches, this is being upgraded to a pair of Packet
Engine gigabit ethernet switches in the core, along with the
existing Cat 5000s and a pair of new Extreme Summit48
switches around the edge.
Recent issues have included renumbering the entire exchange
to provide address expansion space for new members; although
there was significant concern about possible disruption
during this renumbering, in practice it went very smoothly.
Joining fee 10K GBP/year, membership 12K GBP/year. Aggregate
traffic peaks at 280 Mb/s
VIX - Vienna Internet Exchange (Christian Panigl)
http://www.vix.at
Located at Vienna University, based on a Cat 5000. Production
service from early 1997, though still best efforts (no out of
hours access). 32 members, mainly at 10 baseT. 3 bandwidth
suppliers to the premises. Members must have their own
independant international bandwidth and must be RIPE members,
however there are no restrictions on peerings once
connected. Planning to relocate the entire exchange and all
equipment within the building, to increase available space
and to enable out of hours access.
Others
There are some discussions about establishing a Scottish
interconnect, tentatively called ScotIX
Multicast
Discussed within the LINX, but seemingly little
interest. Some experiments over AMS-IX. Randy Bush mentioned
that some experiments are going on at some of the US
exchanges, however these are hampered by the use of DEC
Gigaswitches at all the exchanges in question, as the
Gigaswitches are `unfriendly' to multicast.Solution to this
has been to establish separate connections for multicast.
eix-ops
Keith proposed establishment of an eix-ops mailing for
exchange points operators to exchange experiences. Because
the discussions, particularly those about exchange point
abuse, could be sensitive, it was agreed that this should be
a closed list. Despite it being a closed list, Rob Blokzijl
stated that there would no problem in housing this list at
the NCC.
Action: establish eix-ops mailing list at RIPE NCC
Future of EIX WG
Keith Mitchell explained that he no longer had the time to
chair this group. Despite their being clear support within
the meeting for the continuation of the group, there were
initially no volunteers to take over chairing the
group. Eventually Fearghas McKay offerred to chair the next
EIX WG meeting in Amsterdam.
AOB
Daniele Bovio suggested that, given the comments from
Stockholm about their need to expand to a second location
(Gothenburg), the group start working on guidelines about
when and where there may need to establish additional
exchange points. Comment from Stockholm was that as the ISPs
pay for their connection, they also drive the establishment
of new exchanges; limiting factor is that exchange points are
not essential and providers can always string up point to
point connections.
Randy Bush mentioned a exchange point in Panama that (because
of problems with their local Telco services), was trying to
run an exchange point using a router as a serial
bridge. Randy asked that anyone who had any experience of
such a configuration contact him.
Netnews WG ---------- Chair: Felix Kugler
Scribes: Petra Zeidler/Stefan Sticht Attendees: 58
The meeting was divided in a slot for presentations and a
slot for discussions about ongoing projects.
All actions except A30.N2 have been either done or seen
progress. Actions items A30.N3, A30.N4, and A30.N5 will be
carried forward as they are related to ongoing projects.
In part 1 of the meeting, a number of presentations
concerning actual Usenet issues were given: - crosspost
statistics - Usenet II - inn-2.1 improvements - Usenet's last
mile - recent newgroup attacks & control message
forgeries Refer to the slides and the minutes for details !
Part 2 of the meeting was dedicated to the three major
ongoing projects.
flowmaps - visualization of news traffic flows:
A toolbox to manipulate coordination data and get LOC data
from uumaps & DNS is ready. A set of prototype scripts to
draw news flows onto GIF maps (from Xerox map server) has
been written but the new maps are not yet produced on a
regular basis.
The following work is planned for the next 4 months: -
A30.N4: Felix Kugler to write code for use of whois data and
Names servers - A30.N3: Kai Siering to modify collect software
in order to take advantage of inpath data which is already
collected on a big number of servers; improvement of
visualization software.
newsgroup synchronization:
Traditional group maintenance is cumbersome and not failsafe
even if PGP is used. Furthermore, there is no easy way to
initialize group lists of new servers.
Jonas Luster has presented the framework of a new mechanism
where information about as many hierarchies as possible get
collected, verified and formatted ready to use on a central
"groupsync" server where it can be retrieved by
clients (i.e. an news server) by ftp/http. A first prototype
was promised for October 98.
Actions: - A30.N5: Jonas Luster to produce prototype for a
field test - A31.N1: WG members to contribute references to
checkgroup lists, maintainer addresses, and PGP-keys of
national hierarchies.
Newsbone deployment/netnews-wg administrativa:
The Newsbone documentation has been revised. Many former
requirements have been dropped. In Sept 98, Newsbone had 8
operational participants, three more networks have announced
participation. The status page lists 45 backbone sites with
open online monitoring facilities.
The main netnews-wg projects will get their own homepages
soon. A separate mailing list is planned for the discussion
of Newsbone operational issues where we need 7x24h coverage.
LIR WG ------ Local-IR WG
New Chair: Hans Petter Holen (HPH2) Many thanks to Mike
Norris for his long lasting contribution and for
chairing this meeting !! Scribe: Julia Edwards, RIPE
NCC Hostmaster
Reports RIPE NCC Report APNIC Director General: Paul Wilson
ARIN considering changing minimum allocation from /19 to /20
RIPE NCC Statistics shows that only 20 % uses less than a /20
after a year, and we do plan in a 2 year perspective
Distribution robot at [email protected] Distribution robot
now in place and is documented
http://www.ripe.net/lir/services/status.html
Statistics analysis done every two weeks on zones available
locally result better seems better than average Wishes from
the working group proceed with next level beyond /24 look
into providing historic data
http://www.ripe.net/inaddr/statistics/index.html
Action points
Comments to RIPE-185 (update to "European Internet
Registry Policies and Procedures" before 12/10 main
change: from 90% to 80% before new allocation can be made)
NCC to inform the WG on possible ARIN policy changes
Plenary Session:
Q: what is the distribution robot? A: When one sends a mail
to <[email protected]>, you don't get in touch with
human, but with a robot. Address allocations will be
automatically checked.
TLD WG ------ Chair: Niall O'Reilly Scribe: Lars-Johan Liman
Attendees: 68 (18 ccTLD Registries) Date: 23 September 1998
2. Matters arising from RIPE 30 TLD-WG meeting
Action 31.1: Chair to make minutes from RIPE 29 and 30
available
3. Review Workplan
List of activities unchanged. RIPE CENTR busy with priority
items
Developments since RIPE 30 (without specific agenda items):
Boudewijn Nederkoorn, Harald Alvestrand nominated to WIPO
expert panel.
4. Liaison with other Working Groups
Action 31.2: [DB-WG] Chair to ascertain status of whois
referral feature
Done: feature will soon be ready for testing -- Thanks to NCC
DB-Team
5. RIPE-CENTR Progress
Fay Howard presented Policy Group and Project activities.
Independent CENTR organisation
European focus, members will be ccTLD registries Large,
medium, small levels of contribution Assessment panel: SE,
DK, IT Other countries to submit proposals by 20 October
Report of assessors due 10 November In action early 1999
Budget region 300 kECU
Project activities
Reported already in plenary by Mirjam Kuehne
Technical Workshop (Summer) Administrative Workshop
(September) De-facto reference point for queries: need PR
CENTR Web site -- gateway to ccTLD sites
6. New IANA and Supporting Organisations
Briefing from Daniel Karrenberg on current position
Activity since RIPE 30:
CENTR has published a response to the US White Paper. Daniel
Karrenberg has prepared a background document on how the
Internet is organised in Europe.
Dennis Jennings has drafted a document (in the context of
"Draft 3") expressing a European position on the
"New IANA" and suggesting next steps.
RIPE-NCC has published a response to the Joint IANA and NSI
Documents (Fourth Draft Definition of the "New
IANA").
CENTR has published a response to the Joint IANA and NSI
Documents.
POC have invited CENTR to participate in initiative to define
DNSO
General discussion -- no conclusions To be revisited in
plenary
7. AOB
There was no other business
Routing WG - DSTF ----------------- Chair: Joachim Schmitz
Scribe: Mirjam Kuehne, Julia Edwards Attendees: 99
Working group draft minutes http://www.ripe.net/wg/routing/r31-routing.html
Report from the RPSL Tutorial
http://www.isi.edu/ra/rps/training
Reports on RPSL Deployment
http://www.isi.edu/ra/rps/transition
DSTF ---- Topics PGP implementation
Draft-zsako-ripe-dbsec-pgp-authent-00.txt
Discussion of RPS auth draft Draft-ietf-rps-auth-01.txt
Project for prefix/origin authentication Implementation in
the RIPE database software
Anti-SPAM WG ------------ Chair: James Aldridge, EUnet
Scribe: Petra Zeidler, Xlink
DRAFT MINUTES
1. ADMIN STUFF
Chair: James Aldridge, EUnet Scribe: Petra Zeidler, Xlink
2. GENERAL WG INPUT
2.1 Current problems,major incident reports, etc
"Reverse Spam" - Forged mail headers implicate
innocent third party; the innocent party gets all complaints,
delivery reports, etc.
"Spam Relaying" - main problem in Germany as spam
sending is considered fraudulant.
Problems with unresponsive spam originating provider.
2.2 Means of dealing with spam
ISP Relaying Customer Relaying SMTP port blocking for
incoming/outgoing Blocking known spammers (blacklists)
2.3 Roaming Customers
- setting e.g. local mail smarthost transferred in PPP
negotiation
- tunnelling back to home ISP
- authenticated SMTP
- limited amount relaying (when connecting to home server from
remote address)
2.4 Implications of blocking/restricting SMTP to force use of
ISP's relay
Some people want to be able to send end-to-end
3. CODE OF CONDUCT FOR ISPs ===========================
- Ask customers not to spam
- responsive to spam reports
- coordination of open relay removal (taking advantage of
provider/customer relationship)
- have an abuse@ email address (reference RFCXXXXX standard
email addresses)
- educate people to see where to look
- get complaints fast to block ongoing abuse
- abuse.net to make abuse reporting easy
- blacklist known spam users: = wouldn't work with online
registation ISPs = may be illegal
- IP address use limits (assignment of IP addresses to
customers has additional limitations above existing Regional
Registry rules)
Discussion:
- US: "good" spam (has correct
"From" field)
- Belgium: "database entry" spam (not really
a legally required act)
- gathering addresses from public databases (RIPE,
InterNIC, etc). All databases copyright; proof of
abuse leads to legal action.
- NSI CD-ROM seems to have been withdrawn
- White pages
- "tar pit" - abuse triggers delay in all
SMTP actions limiting rate at which spam can be
transmitted.
- restrict number of recipients in a single SMTP
transaction/message
- Get "typical" spammer's profile so new
ISPs can avoid taking them on.
- get together a common set of terms and conditions -
different laws across Europe - how does this affect
us?
- what existing laws relate to spam?
- what about non-EU countries?
- terminate contract if abuse
- bill for abuse cleanup
- have marketing people write "netiquette"
document
- EU-wide, every ISP netiquette and maybe even have
country spec netiquette
- put pressure on software vendors to not deliver SMTP
servers which are open to third-party relaying in
default configuration.
- technical measures won't last for ever: legal
standards are necessary
- have an RFC say "thou shalt not relay 3rd party
mail"
- "Good netkeeping" /"RIPE
approved" sticker for software with good
defaults
4. CENAR
abuse.net exists last resort will become first duplication of
efforts to be avoided
5. AOB
LINX is hosting a "spam conference" in London in
October
Check maps.vix.com for relaying checker and hints to fix is
open and a lot of other useful information.
Plenary:
Q: Will there be any recommendations on whether there wil be
any code of conduct for relay. A: ISPs should approach
their customers. The providers have relationships with
their customers, the working group will not go after them.
Mbone WG -------- Chair: Kurt Kayser Scribe: Ronnie Mackenzie
Attendees: 68
Date and place of meeting: 23.9.1998, Room-2, RIPE31,
Edinburgh
agreed agenda:
A. Administrative Issues Recognition of Scribe WG-agenda
bashing acceptance of last meetings minutes
B. Outstanding action items
C. Multicast based News distribution
D. Pruning
E. AMX-IX multicast project
F. MBGP & MSDP deployment tests
G. Implementation update - RealPlayer G2 beta
Z. AOB
summary report:
A. Recognition of scribe - thanks to Ronnie Mackenzie who
volunteered.
WG-agenda bashing. Item D. was corrected by Thomas Telkamp
last meeting's minutes were accepted without changes
B. Outstanding action items
AP30.1 Wilfried Wvber & Thomas Telkamp "start
tracking down non-pruning networks on the
ams-mr.att-unisource.net router"
This action item was converted into a presentation by Thomas
Telkamp and put onto the agenda as item D. Action item was
closed
C. Multicast based News distribution
Heiko W. Rupp committed to give a presentation about his
recent developments about a mechanism to deliver
News-articels via Multicast transmission. Unfortunately he
was unable to attend the meeting, but designated a
replacement. The person elected was also unable to give this
presentation, so the chairman decided to present the slides
which were printed by Felix Kugler (thanks again!). Even
without having them seen before, the chairman tried to
explain the mechanism of this great idea using the slides and
comments which were discussed on various mailinglists. These
slides were actually made for a presentation to the IETF.
The mechanism to deliver News articles via Multicast seems to
work (2 productive installation with medium sized ISPs) and
future improvements shall bring ease to the news burdon of
all Internet site maintainers.
D. Pruning.
Thomas Telkamp added this topic, due to his findings out of
the action item AP30.1 from the previous WG meeting. Instead
of just closing the action item as 'done', Thomas basically
found a method to track down non-pruning multicast routers by
sending traffic into an unused address (which he might be able
to register as a 'well-known-no- traffic-address' later...)
After tracking (RPF checks) where this traffic flows, the
likelyhood increases to find multicast routers which are
'behaving' incorrectly by using old/buggy software. Thomas
recommended that a small WG be setup to decide on how to
handle persistant 'offenders'.
E. AMS-IX multicast project
Erik-Jan Bos explained the tests which were done over the
AMS-IX to exchange Mulicast traffic using an extra VLAN on the
Ethernet-Switch and MBGP to exchange the policy information
between the Multicast clouds. Their success proves that MBGP
might become a mature techology and by Peter Lothbergs
elaborations on MBGP the current shape of 'The MBone' is
changing right now. Routing updates and old flood and prune
behaviour of DVMRP (which made up the Mbone as we knew it) are
basically at the end of scalability. The need to apply policy
information went into extensions of BGP, which is the standard
Internet routing protocol nowadays. By using MBGP at an IXP,
such as AMS-IX the efficiency of exchanging and delivering
Multicast traffic will be increased.
F. MBGP & MSDP deployments
Peter Lothberg showed slides that explained the interoperation
of MBGP and MSDP and current topological and technical changes
within the Mbone. MBGP exchances multicast policy information
at an ISPs border to other ISPs. MSDP is being used to let RP
routers talk amongst these ISPs which have an MBGP relation.
This topic was being covered in much deeper detail (despite
not being announced) during the EOF session on Monday+Tuesday
(21.09+ 22.09.). Peter explained some topological changes
which might affect the current Mbone topology. Some of these
tests were made to gain real-life MBGP experience, some needed
to be made, due to hardware overload (too many tunnels == no
more scalability).
G. Implementation update - Realplayer G2 beta
The chairman gave a brief introduction into new features and
developments about the new Realplayer G2. This player can
adjust the streaming server to send data with lower bitrates
due to congestion feedback. It incorporates new codecs that
are behaving better (for a listeners ear) in case of lost
packets. This player also includes a new macro language to
control certain media streams called SMIL. It is an HTML-style
syntax to control via RTSP requests the server and combines
TEXT, VIDEO, AUDIO and slideshow effects. It is also possible
to hyperlink multimedia-content into Webrequests.
Nevertheless most portions of this player remain propriatory
and one must make a conscious decision when deploying such
technology.
Z. AOB
There were some comments about Peter Lothbergs background
about the current changes within the Mbone. It seems that some
parts of the Mbone were kind of segmentated due to parts of
'still-using-DVMRP' and already 'moved-to-MBGP'
environments. Jan Novak from DANTE commented that some
subscribers from TEN34 were 'cut off' without warning. The
chairman advised to inform the contact person for the
Mbone-operations from TEN34 via the Web-contact list.
The chairman informed the WG about a contact from CCIRN
Mbone-WG (Coordinating Commitee for research networks). It
seems that this working group might assist in discussing the
wordwide scope of Mbone deployment issues and topological
questions. Ideas for cooperation are welcome to be fed back
into the CCIRN-WG.
A delegate asked: "Is anyone currently selling Multicast
traffic" ? Peter Lothberg replied: There are two schools
of thought: 1. Hardware vendors want to charge. 2. Bandwidth
providers want to give it away. Peter's suggestion to the
audience was that Europe should do it on the existing
infrastructure otherwise we will be left behind.
Closing - the meeting extended a vote of thanks to the chair.
DNS WG ------ Chair: Ruediger Volk
Ipv6 ----
Minutes of IPv6 Working Group, 24th of Sept. 1998
1. Administrative stuff: Chair: David Kessens (Thomas Trede
apologised) Minutes: Sabrina Waschke Attendees: 81
2. Reports
Report - 6Bone by David Kessens - - Status report there are
now about 300 IPv6 connected sites on the 6bone the trend is
to connect natively instead of using tunnels (slides will be
available at http://www.ripe.net/ripe/meetings//ripe31/presentations/) -
- Information on the 6bone can be found at: see
<http://www.6bone.net>
3. Current status of RIPE regarding address assignments in
IPv6 by Paula Caslav
- - RIPE NCC is in process of discussing the documentation,
finding guidelines and procedures, by taking the IETF draft,
looking at the criteria, what documentation will we need,
working on details with other regional registries and will
have a meeting with them, send than a draft to the relevant
working groups and the RIPE community, final version will be
published - Hopefully ready in January 1999
Question by: David Kessens: Could you give more detail in
the time scale ?
Paula Caslav: November 1998: first draft of procedures
document ready to be discussed among the regional registries
and RIPE January 1999: start allocating IPv6 addresses
(depends on IANA to be ready to allocate to the regional
registries and on the registries to get their databases and
procedures compliant) All regional registries will start
allocating at the same time.
There will be no change in the fee structure for the next
year.
Question by David Kessens: Do you have any comments what
will be different in the assignment guidelines for the TLA's
in the IETF draft and yours ?
Paula Caslav: We might do a slow start mechanism in meaning
of allocating a sub TLA first.
Mirjam Kuehne: We also need to define still how to determine
if an organisation is a transit provider. Many details are
still under discussion.
Comment by the audience: It might be useful to have a
document in this Working Group as soon as possible.
Mirjam Kuehne: We are in the process of collecting input and
will discuss it with the other Working Groups. We receive
requests for IPv6 addresses, some are detailed, some are
just general. We will see how we can implement this in the
operations and procedures.
Paula Caslav: If you have any ideas send them to us or the
mailing list of this Working Group.
2.3. News about manufacturers implementation - - input from
the audience
Bernhard Tuy showed an overview of all vendors and what they
currently support. For details see:
http://www.phoebe.urec.fr/G6 http://www.ipv6.urec.fr/G6
4. General Input from other Working Groups
Routing WG presented by Joachim Schmitz (slides will be
available at http://www.ripe.net/ripe/meetings/ripe31/presentations/)
Do we need an IRR for IPv6 ?
Need for an IPv6 IRR: - - due to the benefits: YES - - plus:
manage interface ipv4 _> ipv6 - - time to early: NO
We need an IPv6 routing registry !
[general acceptence without taking over any concrete
initiative by the audience]
Joachim Schmitz: Call for participation. He expects a
gradual move over, requirements in the beginning are not
very high, so one registry might be enough to start with.
David Kessens: The regional registries also need to think
about assignment policies for AS numbers, they might be
different.
David K: There are several ways to go to a IPv6 routing
registry: 1. just replace IPv4 with IPv6 addresses in RPSL,
and add IPv6 specific support later on 2. a special RPSLv6
draft with all bells and whistles that are
required to do IPv6 routing registries
What is better ?
Joachim Schmitz: Both are needed, because RPSL took some
time to be developed and we need something running soon.
That's not sufficient but better than nothing.
David Kessens: Coming out with an RPSL IPv6 version would
make sense.
5. AOB:
David Kessens: Keep this Working Group and move on because
of the large interest (81 attendees). Discuss the allocation
and assignment process in more detail.
Action points:
31.1 RIPE NCC and all other Regional Internet Registries to
be prepared to start allocating IPv6 address space in
Quarter-1 1999.
Plenary:
Q: What is the current status of RIPE Ipv6 address
assignment input from ncc A: The RIPE NCC and all other
Regional Internet Registries agreed to be prepared to
start allocating IPv6 address space in Quarter-1 1999.
- 13. - Next meetings:
RIPE 32: January 27-29 1999, Amsterdam RIPE 33: May 5-7 1999,
Vienna RIPE 34: September 1999, Amsterdam RIPE 35: January
2000, Amsterdam
- 14. - A.O.B.
Version 4 draft of the bylaws of the new IANA organization;
Rob: the wording of the text will be done by the chair and
input from Niall O'Reilly. No comment from people present.
More than 240 people registered for this meeting. We all
thank Edinburgh University for their hospitality and
especially Keith Mitchell and his colleagues for providing
these excellent facilities!
- 15. - Close