Internet DRAFT - draft-iab-rtr-workshop
draft-iab-rtr-workshop
Internet Architecture Board Steve Deering
INTERNET DRAFT Cisco Systems
15 November 1998 Sue Hares
Merit Networks
Charles E. Perkins
Radia Perlman
Sun Microsystems
Report on the 1998 IAB Routing Workshop
draft-iab-rtr-workshop-00.txt
Status of This Memo
This document is a submission by the Internet Architecture Board
Working Group of the Internet Engineering Task Force (IETF).
Comments should be submitted to the
iab-routing-workshop@external.cisco.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To view the entire list of current Internet-Drafts, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document is an overview of a Routing workshop held by the
Internet Architecture Board during March 25-27, 1998. The major
points of discussion are listed, along with some conclusions and
action items for many of the points of discussion. The full body of
the report will be provided in a separate document.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page i]
Internet Draft Routing Workshop 15 November 1998
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Conclusions and Action Items 2
2.1. Scaling of Unicast Routing and Addressing . . . . . . . . 3
2.1.1. Unicast Routing - Conclusions . . . . . . . . . . 3
2.1.2. Unicast Routing - Action Items . . . . . . . . . 3
2.2. Levels of Addressing of Addressing and Routing . . . . . 3
2.3. Network Address Translation (NAT) devices . . . . . . . . 4
2.3.1. NAT devices - Conclusions . . . . . . . . . . . . 4
2.3.2. NAT devices - Action Items . . . . . . . . . . . 4
2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4.1. Multicast - Conclusions . . . . . . . . . . . . . 4
2.4.2. Multicast - Action Items . . . . . . . . . . . . 5
2.5. Routing Stability . . . . . . . . . . . . . . . . . . . . 6
2.5.1. Routing Stability - Conclusions . . . . . . . . . 6
2.5.2. Routing Stability - Action Items . . . . . . . . 6
2.6. TOS/CoS/Qos . . . . . . . . . . . . . . . . . . . . . . . 6
2.6.1. TOS/CoS/Qos - Action Items . . . . . . . . . . . 7
2.7. Routing Protocol Security . . . . . . . . . . . . . . . . 7
2.7.1. Routing Security - Conclusions . . . . . . . . . 7
2.7.2. Routing Security - Action Items . . . . . . . . . 7
2.8. Routing Policy . . . . . . . . . . . . . . . . . . . . . 7
2.8.1. Routing Policy - Conclusions . . . . . . . . . . 7
2.8.2. Routing Policy - Action Item . . . . . . . . . . 8
2.9. Network to Host Flow of Information . . . . . . . . . . . 8
2.9.1. Host Information - Conclusions . . . . . . . . . 8
2.9.2. Host Information - Action Items . . . . . . . . . 8
2.10. Shorter Topics . . . . . . . . . . . . . . . . . . . . . 9
2.10.1. Multi-strand Trunking . . . . . . . . . . . . . . 9
2.10.2. Routing Diagnostic and Development Tools . . . . 9
2.10.3. Anycast . . . . . . . . . . . . . . . . . . . . . 9
2.10.4. Load Sensitive IGP routing for Best Effort Traffic 10
2.10.5. Geographical Addresses and Renumbering . . . . . 10
3. Summary of Action items 10
3.1. Action Items for the IAB . . . . . . . . . . . . . . . . 10
3.2. Action Items for IETF Working Group Chairs . . . . . . . 11
3.3. Action Items for the IRTF Routing Research Group . . . . 11
A. Participants 12
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 1]
Internet Draft Routing Workshop 15 November 1998
1. Introduction
From March 25 to March 27, 1998 the Internet Architecture Board
(IAB) held a workshop on Routing. The workshop focused on current
problems within the Internet and the long term solutions that should
be addressed. This document summarizes the discussions the group
had on routing, and lists the conclusions reached by the workshop.
Section 2 lists the conclusions reached by the participants of the
workshop and the suggestions for additional work or redirection of
current work. Sections 2.1-2.10 attempt to capture the substance
of the fast-paced discussion. Appendix A contains a list of the
participants who attended the workshop.
The topics covered at length during the IAB workshop were:
1. Scaling of Unicast Routing and Addressing (section 2.1)
2. Unicast Addressing Issues (Section 2.2)
3. The Effect of extending IP version 4 in the Internet by using
Network Address Transformation boxes (Section 2.3)
4. Multicast Routing (Section 2.4)
5. Routing Instability (Section 2.5)
6. Quality of Service Routing (Section 2.6)
7. Routing Security (Section 2.7)
8. BGP Policy (Section 2.8)
9. Flows of information from network routing to hosts for improved
services (Section 2.9)
In addition the following topics were briefly covered:
a. Multi-strand trunking
b. Better Tools for monitoring and diagnosis of network problems
c. Routing protocol bandwidth minimization
d. Automatic renumbering and automatic organization
e. Anycast
f. Load-sensitive Routing
g. Geographical addressing
These shorter topics are contained in section 2.10.
2. Conclusions and Action Items
The participants came to a number of conclusions after the
discussions described in sections 2.1-2.10. These conclusions,
presented in this document, provide summary statements and action
items for the IETF community.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 2]
Internet Draft Routing Workshop 15 November 1998
2.1. Scaling of Unicast Routing and Addressing
2.1.1. Unicast Routing - Conclusions
The participants of the workshop came to the following conclusions
1. Most of the current unicast scaling problems can be fixed with
improved implementation.
2. Some long term systemic issues that may eventually overwhelm the
unicast routing are:
- Flaps - which will only get worse unless work is undertaken
- Multi-homing
3. We'd like more research into what's breaking; not just more data,
but more analysis of the data
The group reviewed the following potential solutions:
- Architected NAT - improving the existing Network Address
Translation schemes to provide better scaling
- IPV6 - deploying an IP version 6 infrastructure
- MAP/Encap - map to aggregatable addresses and encapsulate the
original packet
- Do nothing
- Aggressive Renumbering - try to continue to encourage
re-numbering to improve utilization of the IP version 4 address
space.
- Metro addressing - use a geographical or metropolitan based
addressing scheme
2.1.2. Unicast Routing - Action Items
We recommend that the IRTF Routing Research groupencourage more
analysis of routing data, not just the collection of more data.
2.2. Levels of Addressing of Addressing and Routing
The group examined whether the current Internet has enough levels of
hierarchy in Internet addresses or routing infrastructure. The group
felt the Internet had enough levels of hierarchy for now.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 3]
Internet Draft Routing Workshop 15 November 1998
2.3. Network Address Translation (NAT) devices
2.3.1. NAT devices - Conclusions
Upon reviewing the NATs, the group
1. Noted that NAT devices are fairly widely deployed
2. Identified various issues about the use of NAT devices within the
internet
3. Discussed the interaction between NAT devices and applications
4. Listed the following options regarding NAT devices:
- Have no NATs
- Fix NATs to provide better interaction with the wider
Internet
- Fix applications to interact better with NAT boxes
- Don't do certain things like IP Security (IPSec)
2.3.2. NAT devices - Action Items
1. Forward our concerns, problems and suggestions to the appropriate
working groups
2. Note architectural work outside the NAT working group
3. Suggest to the IAB that it continue to be concerned about the
issues involving NATs
2.4. Multicast
2.4.1. Multicast - Conclusions
Since the multicast model was created, many multicast applications
have been tried over the Internet multicast routing fabric. The
group began to discuss the multicast model in terms of enabling
multicast applications to run efficiently and scale toward the future
growth. Multicast applications vary in the requirements they place
on the multicast routing.
Multicast applications may have a varying:
- number of sources,
- number of receivers,
- amount of data,
- amount of data in a burst, and length of quiet periods
- number of groups utilized per application or per group of
cooperating applications,
- amount of time during which the group exists, and
- topological distance between members of the group.
- volatility of membership
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 4]
Internet Draft Routing Workshop 15 November 1998
Multicast routing must provide the flexibility to support the
varying requirements of different multicast applications. The
current multicast model establishes multicast routing paths upon
reception of a data packet. The discussion on the viability of the
multicast model examined the viability of the model in terms of the
uses of multicast routing by applications and the scalability to
full Internet usage. The current multicast model was examined to
determine if the model is still viable for the Internet today. For
example, providing for many groups of small conferences (few people
to few remote people) with global topological scope has bad scaling
characteristics given the current multicast model.
The group felt the existing multicast protocols and multicast should
be evaluated in terms of the requirements listed above. The group
suggested that the evaluation should include the multicast protocols
DVMRP [5], MOSPF [8], PIM [4], CBT [2], and Express (an unpublished
single-source multicast model proposed by Hugh Holbrook and David
Cheriton), as well as the following mechanisms used by multicast
applications:
1. Registering of the Core or the RP (Rendevous Point),
2. Having the ID of the group include the core, and having joins
specify the core
3. Having the ID of the group include the core, and having joins and
data specify both
4. Sending data via unicast to all members, and
5. Sending data via unicast transport to the RP.
The group acknowledged that the current multicast model does not
scale well for all scenarios that applications use.
The group noted that reliable multicast is surprisingly orthogonal to
the issues about the scaling of the multicast model to all possible
applications.
2.4.2. Multicast - Action Items
Encourage evaluation and written reports on the evaluation of these
multicast protocols and mechanisms for different types of protocols.
Notify the IRTF Routing Research Group of the need to charter
activity in this area.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 5]
Internet Draft Routing Workshop 15 November 1998
2.5. Routing Stability
2.5.1. Routing Stability - Conclusions
Damping the effects of route updates enhances stability, but possibly
at the cost of reachability for some prefixes. A prefix can be
damped and reachable via another path, so that for some prefixes the
effects of damping are more serious than for other prefixes. The
performance of various algorithms for enhancing stability should
be measured by recording whether the affected route prefixes are
reachable or not reachable. Using current damping approaches,
approximately 1% of the prefixes are affected at any one point in
time. We should try to find out how many prefixes are unreachable
because of damping.
2.5.2. Routing Stability - Action Items
The conclusion is that this effort merits continued investigation.
The IRTF Routing Research Group should measure how stable things are,
and if stability is an issue, to study methods of making things more
stable.
2.6. TOS/CoS/Qos
The group noted that the exact definitions of the terms Type of
Service (ToS), Class of Service (CoS), and Quality of Service (QoS)
are imprecise in the current usage. The start of the discussion was
to define the terminology as follows:
- ToS - defined as hop by hop routing based on destination plus TOS
bits [9]
- CoS - defined as classes of service based on service contracts.
These classes of service are enabled by a variety of mechanisms
which include: queuing and multiple physical or link level
paths.
- QoS routing - defined as managing routes that meet certain
quality of service constraints, and involving the following
steps:
* the routing of the resource requests
* setting up a path that satisfies the constraints
* routing data accordingly
There is no smooth dividing line between between ToS and QoS. ToS is
relative. Qos is absolute. The group discussed whether there is a
demand for ToS, CoS and QoS. Differentiated-services [3] as discussed
in the IETF is ToS++.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 6]
Internet Draft Routing Workshop 15 November 1998
The group also discussed a more general concept of "Constraint
Based Routing" which was defined as traffic engineering on massive
flows. Constraint based routing allows the providers to utilize
the bandwidth in their network to handle traffic requests of
users. Constraint based routing (besides enabling policy management
techniques) allows providers to route traffic based on the
characteristics of the traffic flows.
2.6.1. TOS/CoS/Qos - Action Items
We recommend that IETF should look into the issue of Constraint Based
Routing.
2.7. Routing Protocol Security
2.7.1. Routing Security - Conclusions
After a lengthy discussion of the various problems of network
security, the group notes that:
1. Routers need intrinsic system security as good as or better than
any host computer.
2. Improving router security will not solve all problems.
3. Console access to the router can do everything.
4. One compromised router can create disaster.
5. ISPs and vendors should consider taking some control traffic out
of band, due to lack of wire speed authentication.
6. We discussed other issues that will be passed on to the
appropriate people involved with network security.
7. Identified areas of work to improve things (e.g., wire speed
authentication).
2.7.2. Routing Security - Action Items
The IETF should encourage work on "wire speed" authentication,
pair-wise authentication of routers in routing protocols, and
Byzantine robustness [6] in routing protocols.
2.8. Routing Policy
2.8.1. Routing Policy - Conclusions
During our discussion on routing policy the group reviewed what could
be done with BGP. The group noted that:
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 7]
Internet Draft Routing Workshop 15 November 1998
1. Some routing policies requested by ISPs or NSPs are not solvable
with BGP. Some of these "unsolvable" routing policies can be put
into effect using tunnels and static configuration.
2. BGP is only a mechanism for announcing reachability
3. BGP routing controls traffic direction regardless of traffic
volume.
4. BGP policy management is too delicate, too easy to mess up or
fragile.
5. Router Configuration Language is very complex, error-prone
6. Can't do symmetric routing so ISPs/NSPs/Enterprise nets should
deal with it.
The group concluded the Internet needed a better routing policy
specification language.
2.8.2. Routing Policy - Action Item
Pass the concerns about the Routing Policy Syntax Language (RPSL) [1]
to chairs of the Routing Policy Syntax (RPS) working group [11].
2.9. Network to Host Flow of Information
2.9.1. Host Information - Conclusions
Publishing information about traffic statistics along infrastructure
routes could improve the way Internet services replicate data for
retrieval from various sites. This replication could be especially
important for the retrieval of information off the web. Currently,
web pages refer people to caches local to their sites; for instance,
a European site might be used for United Kingdom customers and a US
site for North American customers. Proponents of web caches want to
auto-configure the locations of web caches so a user's web browser
can automatically discover the local cache. Other applications share
this need for finding the best cache for a particular service.
2.9.2. Host Information - Action Items
The group recommends a BOF be held on Measuring Path Characteristics.
Measurement of path characteristics should include:
- format for exchange of measurement data
- mechanisms for distribution of measurement data
- IPPM working group [7] is dealing with issues within the
measurement problem space.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 8]
Internet Draft Routing Workshop 15 November 1998
2.10. Shorter Topics
2.10.1. Multi-strand Trunking
PPP did multi-link in a way that had too much computation and
could not be used for faster links. Internet technology should
treat multiple parallel trunks as 1 link at the IP layer, but with
multi-dimensional metrics.
2.10.1.1. Multi-strand Trunking - Action Items
There is design and development work at layer two which should be
done to support the multiple parallel trunks. This layer two work
is outside the scope of the IETF. Layer three routing should support
richer metrics in OSPF.
2.10.2. Routing Diagnostic and Development Tools
2.10.2.1. Routing Diagnostics - Conclusions
1. It would be nice to have an Authoritative Database listing those
prefixes permitted from each AS. The authoritative data base was
attempted before without success, but the group felt it might be
useful to try again to create such an Authoritative Database.
2. SNMP version 3 should be deployed in order to make use of better
authentication, scope and rate limiting
3. Remotely-controlled traffic monitors should be used to measure
traffic
4. Better tools are needed for pro-active problem detection
2.10.2.2. Routing Diagnostics - Action Items
1. Authoritative Database should be encouraged within the Internet
2. SNMP version 3 working groups should be notified about the issues
about authentication, scope, and rate limiting.
3. Encourage funding of better tools for remotely controlled traffic
sources and pro-active problem detection.
2.10.3. Anycast
2.10.3.1. Anycast - Conclusions
1. We need a document describing the benefits and deficits of
anycast.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 9]
Internet Draft Routing Workshop 15 November 1998
2. Local-scoped well-known anycast addresses will be useful to
applications.
2.10.3.2. Anycast - Action Items
A BOF should be held to plan work on anycast.
If a working group forms, a paper on the benefits and deficits of
anycast should be included as part of the charter.
2.10.4. Load Sensitive IGP routing for Best Effort Traffic
2.10.4.1. Load Sensitive IGP - Conclusions
While load sensitive routing is interesting in some ways, it cannot
be considered until certain problems are worked out. Currently
constraint based routing is assigning administrative metrics to allow
routing to adapt to different traffic patterns. Load sensitive
routing may increase oscillation and instability of routes. This
instability of routes, sometimes called churn, may affect the ability
of the routing infrastructure to scale.
Load sensitive routing would allow IGPs to better utilize links.
Past and current efforts in load sensitive routing include: QOS
OSPF [10], Q-OSPF [10], and load sensitive routers developed by BBN.
2.10.4.2. Load Sensitive IGP - Action items
IRTF Routing Research group chair and Routing Area Director should
discuss this area and determine what portions of Load Sensitive IGP
routing are ready for IETF, and which portions require additional
research.
2.10.5. Geographical Addresses and Renumbering
This topic was discussed, but without any conclusions or action
items.
3. Summary of Action items
3.1. Action Items for the IAB
1. The IAB should be concerned about the issues involving NATs
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 10]
Internet Draft Routing Workshop 15 November 1998
2. Authoritative Database (for addresses within domains) should be
encouraged within the Internet
3. Encourage funding of better tools for remotely controlled traffic
sources and pro-active problem detection.
3.2. Action Items for IETF Working Group Chairs
1. NAT: Forward our concerns, problems and suggestions to the
appropriate working groups
2. We recommend that IETF should work the issue of Constraint Based
Routing.
3. The IETF should encourage work on "wire speed" authentication,
pair-wise authentication of routers in routing protocols, and
Byzantine robustness in routing protocols.
4. Pass the concerns about the Routing Policy Syntax Language (RPSL)
to the Routing Policy Syntax (RPS) working group chair.
5. The group recommends a BOF be held on Measuring Path
Characteristics. The BOF should consider the data exchange
format of measurement and mechanisms to distribution of data
mechanism. It is noted that the IPPM working group is dealing
with issues within the measurement problem space.
6. There is layer two work which should be done to support the
multiple parallel trunks which is outside the scope of the IETF.
Layer three routing should support richer metrics in OSPF.
7. SNMP version 3 working groups should be notified about the issues
about authentication, scope, and rate limiting.
8. A BOF should be held to plan work on anycast. Recommend that a
document on the benefits and deficits of anycast should be part
of the proposed working group charter.
3.3. Action Items for the IRTF Routing Research Group
1. We recommend that the IRTF Routing Research working group try to
encourage more analysis of routing data, not just the collection
of more data.
2. Encourage evaluation and written reports on the evaluation of
these multicast protocols and mechanisms for different types of
protocols
3. IRTF Routing Research group chair and Routing Area Director
should discuss this area and determine what portions of Load
Sensitive IGP routing are ready for IETF, and which portions
require additional research.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 11]
Internet Draft Routing Workshop 15 November 1998
A. Participants
Harald Alvestrand Harald.Alvestrand@maxware.no,
Fred Baker fred@cisco.com,
Jeff Burgan burgan@corp.home.net,
Brian Carpenter brian@hursley.ibm.com,
Noel Chiappa jnc@ginger.lcs.mit.edu,
Rob Coltun rcoltun@fore.com,
Steve Deering deering@cisco.com,
Deborah Estrin estrin@usc.edu,
Dino Farinacci dino@cisco.com,
Paul Francis francis@slab.ntt.co.jp,
Elise Gerich epg@home.net,
Joel Halpern jhalpern@newbridge.com,
Sue Hares skh@merit.edu,
Cyndi Jung cmj@3Com.com,
Dave Katz dkatz@jnx.com,
Tony Li tli@juniper.net,
Peter Lothberg roll@stupi.se,
Louis Mamakos louie@uu.net,
Dave Meyer dmm@cisco.com,
Keith Moore moore@cs.utk.edu,
Bob Moskowitz rgm@htt-consult.com,
Thomas Narten narten@raleigh.ibm.com,
Vern Paxson vern@ee.lbl.gov,
Charlie Perkins Charles.Perkins@Eng.Sun.COM,
Radia Perlman Radia.Perlman@East.Sun.COM,
Yakov Rekhter yakov@cisco.com,
Allyn Romanow allyn@MCI.NET,
Martha Steenstrup msteenst@bbn.com,
George Swallow swallow@cisco.com,
References
[1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer,
M. Terpstra, and C. Villamizar. Routing policy specification
language (RPSL). Request for Comments (Proposed Standard) 2280,
Internet Engineering Task Force, January 1998.
[2] T. Ballardie. Core based trees (CBT) multicast routing
architecture. Request for Comments (Experimental) 2201,
Internet Engineering Task Force, September 1997.
[3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and
W. Weiss. An Architecture for Differentiated Services.
draft-ietf-diffserv-arch-02.txt, October 1998. (work in
progress).
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 12]
Internet Draft Routing Workshop 15 November 1998
[4] S. Deering. Protocol independent multicast-sparse mode
(PIM-SM): protocol specification. Request for Comments
(Experimental) 2117, Internet Engineering Task Force, June 1997.
[5] S. Deering, C. Partridge, and D. Waitzman. Distance vector
multicast routing protocol. Request for Comments (Experimental)
1075, Internet Engineering Task Force, November 1988.
[6] Charlie Kaufman, Radia Perlman, and Mike Speciner. Network
Security: Private Communication in a Public World, pages
462--465. Prentice-Hall, Inc., 1995.
[7] W. Leland and M. Zekauskas (chairs). IP Performance Metrics
(IPPM), 1997.
http://www.ietf.org/html.charters/ippm-charter.html.
[8] J. Moy. Multicast extensions to OSPF. Request for Comments
(Proposed Standard) 1584, Internet Engineering Task Force, March
1994.
[9] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers. draft-ietf-diffserv-header-04.txt, October 1998.
(work in progress).
[10] H. Sandick and E. Crawley (chairs). QoS Routing (qosr), 1997.
http://www.ietf.org/html.charters/qosr-charter.html.
[11] C. Villamizar and C. Alaettinoglu (chairs). Routing Policy
Syntax (RPS), 1995.
http://www.ietf.org/html.charters/rps-charter.html.
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 13]
Internet Draft Routing Workshop 15 November 1998
Author's Addresses
Questions about this memo can be directed to:
Stephen E. Deering Susan Hares
Cisco Systems, Inc. Merit, Inc.
170 West Tasman Drive 1071 Beal Avenue,
San Jose, CA 95134-1706 Ann Arbor, MI 48109
USA USA
Phone: +1 408 527-8213 Phone: +1 313 936-2095
EMail: deering@cisco.com EMail: skh@merit.edu
Radia Perlman Charles E. Perkins
Sun Microsystems Laboratories Sun Microsystems Laboratories
2 Elizabeth Drive 15 Network Circle
Chelmsford, MA 01824 Menlo Park, CA 94025
USA USA
Phone: +1 978 442-3252 Phone: +1 650 786-6464
EMail: Radia.Perlman@sun.com EMail: cperkins@eng.sun.com
Fax: +1 650 786-6445
Deering, Hares, Perlman, Perkins Expires 15 April 1999 [Page 14]
