Internet DRAFT - draft-ietf-grow-large-communities-usage
draft-ietf-grow-large-communities-usage
Global Routing Operations J. Snijders
Internet-Draft J. Heasley
Intended status: Informational NTT
Expires: October 21, 2017 M. Schmidt
i3D.net
April 19, 2017
Use of BGP Large Communities
draft-ietf-grow-large-communities-usage-07
Abstract
This document presents examples and inspiration for operator's
application of BGP Large Communities. Based on operational
experience with BGP Communties, this document suggests logical
categories of BGP Large Communities and demonstrates an orderly
manner of organizing community values within them to achieve typical
goals in routing policy. Any operator can consider using the
concepts presented as the basis for their own BGP Large Communities
repertoire.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 21, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Snijders, et al. Expires October 21, 2017 [Page 1]
Internet-Draft Use of BGP Large Communities April 2017
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Design Overview . . . . . . . . . . . . . . . . . . . . . 3
2.1. Informational Communities . . . . . . . . . . . . . . . . 4
2.2. Action Communities . . . . . . . . . . . . . . . . . . . 4
3. Examples of Informational Communities . . . . . . . . . . . . 5
3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. An ISO 3166-1 Numeric Function . . . . . . . . . . . 5
3.1.2. An UN M.49 Region Function . . . . . . . . . . . . . 5
3.2. Relation Function . . . . . . . . . . . . . . . . . . . . 6
3.3. Combining Informational Communities . . . . . . . . . . . 6
4. Examples of Action Communities . . . . . . . . . . . . . . . 7
4.1. Selective NO_EXPORT . . . . . . . . . . . . . . . . . . . 7
4.1.1. ASN Based Selective NO_EXPORT . . . . . . . . . . . . 7
4.1.2. Location Based Selective NO_EXPORT . . . . . . . . . 7
4.2. Selective AS_PATH Prepending . . . . . . . . . . . . . . 8
4.2.1. ASN Based Selective AS_PATH Prepending . . . . . . . 8
4.2.2. Location Based Selective AS_PATH Prepending . . . . . 9
4.3. Manipulation of the LOCAL_PREF Attribute . . . . . . . . 9
4.3.1. Global Manipulation of LOCAL_PREF . . . . . . . . . . 10
4.3.2. Region Based Manipulation of LOCAL_PREF . . . . . . . 10
4.3.3. Note of Caution for LOCAL_PREF Functions . . . . . . 11
4.4. Route Server Prefix Distribution Control . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
BGP Large Communities [RFC8092] provide a mechanism to signal opaque
information between Autonomous Systems (ASs). In very much the same
way that [RFC1998] provides a concrete real-world application for
[RFC1997] communities, this document presents examples of how
operators might utilize BGP Large Communities to achieve various
goals. This document draws on the experience of operator communities
such as NANOG [1] and NLNOG [2].
Snijders, et al. Expires October 21, 2017 [Page 2]
Internet-Draft Use of BGP Large Communities April 2017
2. The Design Overview
BGP Large Communities are composed of three 4-octet fields. The
first is the Global Administrator (GA) field, whose value is the
Autonomous System Number (ASN) of the AS that has defined the meaning
of the remaining two 4-octet fields, known as "Local Data Part 1" and
"Local Data Part 2". This document describes an approach where the
"Local Data Part 1" field contains a function identifier and the
"Local Data Part 2" contains a parameter value. Using the canonical
notation this format can be summarized as "ASN:Function:Parameter".
+----------------------+---------------+
| RFC 8092 | this document |
+----------------------+---------------+
| Global Administrator | ASN |
| Local Data Part 1 | Function |
| Local Data Part 2 | Parameter |
+----------------------+---------------+
A mapping table on the use of fields in BGP Large Communities between
[RFC8092] and this document.
Table 1: Field Mapping
In contemporary deployments of both BGP Communities [RFC1997] and BGP
Large Communities, the function of a community can be divided into
two categories:
o Informational Communities
o Action Communities
Throughout the document a topology of four ASs is used to illustrate
the use of communities in the following configuration:
AS 65551
|
^
|
AS 64497
/ \
^ \
/ ^
AS 64498 \
| |
`<->- AS 64499
Snijders, et al. Expires October 21, 2017 [Page 3]
Internet-Draft Use of BGP Large Communities April 2017
AS 64497 obtains transit services from (is a customer of) AS 65551, a
4-octet ASN. AS 64497 provides transit services to both AS 64498 and
AS 64499. AS 64498 and AS 64499 maintain a peering relationship in
which they only exchange their customer routes.
The opaque nature of BGP Large Communities allows for rapid
deployment of new features or changes to their routing policy that
perform an action. Operators are encouraged to publicly publish and
maintain documentation on the purpose of each BGP Large Community,
both informational and action, that they support or are visible in
BGP RIBs.
2.1. Informational Communities
Informational Communities are labels for attributes such as the
origin of the route announcement, the nature of the relation with an
EBGP neighbor or the intended propagation audience. Informational
Communities can also assist in providing valuable information for
day-to-day network operations such as debugging or capacity planning.
The Global Administrator field is set to the ASN which labels the
routes with the Informational Communities. For example, AS 64497
might add a community with the GA 64497 to a route accepted from an
IBGP or EBGP neighbor as a means of signaling that it was imported in
a certain geographical region.
In general, the intended audiences of Informational Communities are
downstream networks and the Global Administrator itself, but any AS
could benefit from receiving these communities.
2.2. Action Communities
Action Communities are added as a label to request that a route be
treated in a particular way within an AS. The operator of the AS
defines a routing policy that adjusts path attributes based on the
community. For example, the route's propagation characteristics, the
LOCAL_PREF (local preference), the next-hop, or the number of AS_PATH
prepends to be added when it is received or propagated can be
changed.
The Global Administrator field is set to the ASN which has defined
the functionality of that BGP Large Community and is the ASN that is
expected to perform the action. For example, AS 64499 might label a
route with a BGP Large Community containing GA 64497 to request that
AS 64497 perform a pre-defined action on that route.
In general, the intended audience of Action Communities are transit
providers taking action on behalf of a customer or the Global
Snijders, et al. Expires October 21, 2017 [Page 4]
Internet-Draft Use of BGP Large Communities April 2017
Administrator itself, but any AS could take action if they choose and
any AS could add an Action Community with the GA of a non-adjacent
ASN. However, note that an Action Community could also be
informational. Its presence is an indicator that the GA may have
performed the action and that an AS in the AS_PATH requested it.
Operators are recommended to publish the relative order in which
Action Communities (both BGP Communities and BGP Large Communities)
are processed in their routing policy.
3. Examples of Informational Communities
3.1. Location
An AS, AS 64497 in these examples, may inform other networks about
the geographical region where AS 64497 imported a route by labeling
it with BGP Large Communities following one of the following schemes
or a combination of them.
3.1.1. An ISO 3166-1 Numeric Function
AS 64497 could assign a value of 1 to the Function field to designate
the content of the Parameter field as an ISO-3166-1 [3] numeric
country identifier.
+---------------------+---------------------------------------------+
| BGP Large Community | Description |
+---------------------+---------------------------------------------+
| 64497:1:528 | Route learned in the Netherlands |
| 64497:1:392 | Route learned in Japan |
| 64497:1:840 | Route learned in the United States of |
| | America |
+---------------------+---------------------------------------------+
Example documentation for Informational Communities deployed by AS
64497 to describe the location where a route was imported using ISO
3166-1 numeric identifiers.
Table 2: Information: ISO 3166-1
3.1.2. An UN M.49 Region Function
AS 64497 could assign a value of 2 to the Function field to designate
the content of the Parameter field as the M.49 numeric code published
by the United Nations Statistics Division (UNSD) [4] for macro
geographical (continental) regions, geographical sub-regions, or
selected economic and other groupings.
Snijders, et al. Expires October 21, 2017 [Page 5]
Internet-Draft Use of BGP Large Communities April 2017
+---------------------+-------------------------------+
| BGP Large Community | Description |
+---------------------+-------------------------------+
| 64497:2:2 | Route learned in Africa |
| 64497:2:9 | Route learned in Oceania |
| 64497:2:145 | Route learned in Western Asia |
| 64497:2:150 | Route learned in Europe |
+---------------------+-------------------------------+
Example documentation for Informational Communities deployed by AS
64497 to describe the location where a route was imported using M.49
numeric codes published by the United Nations Statistics Division.
Table 3: Information: UNSD Regions
3.2. Relation Function
An AS, AS 64497 in this example, could assign a value of 3 to the
Function field to designate the content of the Parameter field as a
number indicating whether the route originated inside its own network
or was learned externally, and if learned externally, it might
simultaneously characterize the nature of the relation with that
specific EBGP neighbor.
+---------------------+---------------------------------------+
| BGP Large Community | Description |
+---------------------+---------------------------------------+
| 64497:3:1 | Route originated internally |
| 64497:3:2 | Route learned from a customer |
| 64497:3:3 | Route learned from a peering partner |
| 64497:3:4 | Route learned from a transit provider |
+---------------------+---------------------------------------+
Example documentation for Informational Communities deployed by AS
64497 to describe the relation to the ASN from which the route was
learned.
Table 4: Information: Relation
3.3. Combining Informational Communities
A route may be labeled with multiple Informational Communities. For
example, a route learned in the Netherlands from a customer might be
labeled with communities 64497:1:528, 64497:2:150 and 64497:3:2 at
the same time.
Snijders, et al. Expires October 21, 2017 [Page 6]
Internet-Draft Use of BGP Large Communities April 2017
4. Examples of Action Communities
4.1. Selective NO_EXPORT
As part of an agreement, often a commercial transit agreement,
between AS 64497 and AS 64498, AS 64497 might expose BGP traffic
engineering functions to AS 64498. One such BGP traffic engineering
function could be selective NO_EXPORT, which is the selective
filtering of a route learned from one AS, AS 64498, to certain EBGP
neighbors of the GA, AS 64497.
4.1.1. ASN Based Selective NO_EXPORT
AS 64497 could assign a value of 4 to the Function field to designate
the content of the Parameter field as a neighboring ASN to which a
route should not be propagated.
+---------------------+---------------------------------+
| BGP Large Community | Description |
+---------------------+---------------------------------+
| 64497:4:64498 | Do not export route to AS 64498 |
| 64497:4:64499 | Do not export route to AS 64499 |
| 64497:4:65551 | Do not export route to AS 65551 |
+---------------------+---------------------------------+
Example documentation for Action Communities deployed by AS 64497 to
expose a BGP traffic engineering function which selectively prevents
the propagation of routes to the neighboring ASN specified in the
Parameter field.
Table 5: Action: ASN NO_EXPORT
4.1.2. Location Based Selective NO_EXPORT
AS 64497 could assign a value of 5 to the Function field to designate
the content of the Parameter field as an ISO 3166-1 numeric country
identifier within which a labeled route is not propagated to EBGP
neighbors. However, this might not prevent one of those EBGP
neighbors from learning that route in another country and making it
available in the country specified by the BGP Large Community.
Snijders, et al. Expires October 21, 2017 [Page 7]
Internet-Draft Use of BGP Large Communities April 2017
+-----------------+-------------------------------------------------+
| BGP Large | Description |
| Community | |
+-----------------+-------------------------------------------------+
| 64497:5:528 | Do not export to EBGP neighbors in the |
| | Netherlands |
| 64497:5:392 | Do not export to EBGP neighbors in Japan |
| 64497:5:840 | Do not export to EBGP neighbors in the United |
| | States of America |
+-----------------+-------------------------------------------------+
Example documentation for Action Communities deployed by AS 64497 to
expose a BGP traffic engineering function which selectively prevents
the propagation of routes to all EBGP neighbors in the geographical
region specified in the Parameter field.
Table 6: Action: NO_EXPORT in Region
4.2. Selective AS_PATH Prepending
As part of an agreement between AS 64497 and AS 64498, AS 64497 might
expose BGP traffic engineering functions to AS 64498. One such BGP
traffic engineering function could be selective prepending of the
AS_PATH with AS 64497 to certain certain EBGP neighbors of AS 64497.
4.2.1. ASN Based Selective AS_PATH Prepending
AS 64497 could assign a value of 6 to the Function field to designate
the content of the Parameter field as a neighboring ASN to which
prepending of the AS_PATH with AS 64497 is requested on propagation
of the route. Additional AS_PATH prepending functions might also be
defined to support multiples of prepending, that is two, three or
more prepends of AS 64497.
+---------------------+------------------------------------------+
| BGP Large Community | Description |
+---------------------+------------------------------------------+
| 64497:6:64498 | Prepend 64497 once on export to AS 64498 |
| 64497:6:64499 | Prepend 64497 once on export to AS 64499 |
| 64497:6:65551 | Prepend 64497 once on export to AS 65551 |
+---------------------+------------------------------------------+
Example documentation for Action Communities deployed by AS 64497 to
expose a BGP traffic engineering function which selectively prepends
the AS_PATH with AS 64497 when propagating the route to the specified
EBGP neighbor.
Table 7: Action: Prepend to ASN
Snijders, et al. Expires October 21, 2017 [Page 8]
Internet-Draft Use of BGP Large Communities April 2017
4.2.2. Location Based Selective AS_PATH Prepending
AS 64497 could assign a value of 7 to the Function field to designate
the content of the Parameter field as an ISO 3166-1 numeric country
identifier to which the prepending of the AS_PATH with AS 64497 is
requested on propagation of the route to all EBGP neighbors in that
region.
+------------------+------------------------------------------------+
| BGP Large | Description |
| Community | |
+------------------+------------------------------------------------+
| 64497:7:528 | Prepend once to EBGP neighbors in the |
| | Netherlands |
| 64497:7:392 | Prepend once to EBGP neighbors in Japan |
| 64497:7:840 | Prepend once to EBGP neighbors in United |
| | States of America |
+------------------+------------------------------------------------+
Example documentation for Action Communities deployed by AS 64497 to
expose a BGP traffic engineering function which selectively prepends
the AS_PATH with AS 64497 when propagating the route to all EBGP
neighbors in the geographical region specified in the Parameter
field.
Table 8: Action: Prepend in Region
4.3. Manipulation of the LOCAL_PREF Attribute
As part of an agreement between AS 64497 and AS 64498, AS 64497 might
expose BGP traffic engineering functions to AS 64498. One such BGP
traffic engineering function might allow AS 64498 to manipulate the
value of the LOCAL_PREF attribute of routes learned from AS 64498
within AS 64497, even though the LOCAL_PREF attribute is non-
transitive and is not propagated to EBGP neighbors.
The LOCAL_PREF value of routes are locally significant within each AS
and are impossible to list in this document. Instead, the typical
LOCAL_PREF values could be classified as a hierarchy and a BGP Large
Community function exposed allowing an EBGP neighbor to affect the
LOCAL_PREF value within the specified GA. The following example list
defines the classes of routes in the order of descending LOCAL_PREF
value and assigns a function identifier which could be used in the
Function field of a BGP Large Community.
Snijders, et al. Expires October 21, 2017 [Page 9]
Internet-Draft Use of BGP Large Communities April 2017
+----------+--------------------------------------------------------+
| Function | Preference Class |
+----------+--------------------------------------------------------+
| 8 | Normal customer route |
| 9 | Backup customer route |
| 10 | Peering route |
| 11 | Upstream transit route |
| 12 | Fallback route, to be installed if no other path is |
| | available |
+----------+--------------------------------------------------------+
Table 9: Action: Preference Function Identifiers
4.3.1. Global Manipulation of LOCAL_PREF
AS 64497 could place one of the previously defined Preference
Function Identifiers in the Function field and set the value 0 in the
Parameter field to designate that the LOCAL_PREF associated with that
function identifier should be applied for that route throughout the
whole AS.
+---------------------+---------------------------------------------+
| BGP Large Community | Description |
+---------------------+---------------------------------------------+
| 64497:9:0 | Assign LOCAL_PREF for a customer backup |
| | route |
| 64497:10:0 | Assign LOCAL_PREF for a peering route |
| 64497:12:0 | Assign LOCAL_PREF for a fallback route |
+---------------------+---------------------------------------------+
Example documentation for Action Communities deployed by AS 64497 to
expose a BGP traffic engineering function which allows a BGP neighbor
to globally manipulate the LOCAL_PREF attribute for the route within
AS 64497.
Table 10: Action: Global LOCAL_PREF Manipulation
4.3.2. Region Based Manipulation of LOCAL_PREF
AS 64497 could place one of the previously defined Preference
Function Identifiers in the Function field and use an UN M.49 numeric
region identifier in the Parameter field to designate the
geographical region within which the non-default LOCAL_PREF
associated with that function identifier should be applied to the
route. The value of the LOCAL_PREF attribute should not deviate from
the default for that route class in any region not specified by one
or more of these Action Communities.
Snijders, et al. Expires October 21, 2017 [Page 10]
Internet-Draft Use of BGP Large Communities April 2017
+--------------+----------------------------------------------------+
| BGP Large | Description |
| Community | |
+--------------+----------------------------------------------------+
| 64497:9:3 | Assign the LOCAL_PREF value equivalent to a |
| | customer backup class route on BGP routers in the |
| | North America region |
| 64497:10:5 | Assign the LOCAL_PREF value equivalent to a |
| | peering class route on BGP routers in the South |
| | America region |
| 64497:12:142 | Assign the LOCAL_PREF value equivalent to a |
| | fallback class route on BGP routers in the Asia |
| | region |
+--------------+----------------------------------------------------+
Example documentation for Action Communities deployed by AS 64497 to
expose a BGP traffic engineering function which allows a BGP neighbor
to selectively manipulate the LOCAL_PREF attribute within AS 64497 in
the geographical region specified in the Parameter field.
Table 11: Action: Regional LOCAL_PREF Manipulation
4.3.3. Note of Caution for LOCAL_PREF Functions
The LOCAL_PREF attribute strongly influences the BGP Decision
Process, which in turn affects the scope of route propagation.
Operators should take special care when using Action Communities that
decrease the LOCAL_PREF value, and the degree of preference, to a
value below that of another route class. Some of the unintended BGP
states that might arise as a result of these traffic engineering
decisions are described as "BGP Wedgies" in [RFC4264].
4.4. Route Server Prefix Distribution Control
Route Servers [RFC7947] use BGP to broker network reachability
information among their clients. As not all route server clients may
wish to interconnect with each other, the route server operator will
usually implement a mechanism to allow each client to control the
route server's export routing policy, as described in Section 4.6 of
[RFC7948]. One widely-used mechanism is a route server specific
adaption of "ASN Based Selective NO_EXPORT" (Section 4.1.1).
An example BGP Large Communities policy which enables client-
controlled prefix distribution for a route server operating as AS
64497, is outlined as follows:
Snijders, et al. Expires October 21, 2017 [Page 11]
Internet-Draft Use of BGP Large Communities April 2017
+-------------------+-----------------------------------------------+
| BGP Large | Description |
| Community | |
+-------------------+-----------------------------------------------+
| 64497:13:peer-as | Explicitly prevent announcement of route to |
| | peer-as |
| 64497:14:peer-as | Explicitly announce route to peer-as |
| 64497:13:0 | Do not announce route to any peers by default |
| 64497:14:0 | Announce route to all peers by default |
+-------------------+-----------------------------------------------+
Table 12: Action: Route Server Prefix Distribution Control
Multiple BGP Large Community values can be used together to implement
fine-grained route distribution control. For example, route server
client AS 64500 might wish to use a route server for interconnecting
to all other clients except AS 64510. In this case, they would label
all their outbound routes to the route server with 64497:14:0 (to
announce to all clients by default) and 64497:13:64510 (to prevent
announcement to AS 64510).
Alternatively, route server client AS 64501 may have a selective
routing policy and may wish to interconnect with only AS 64505 and AS
64506. This could be implemented by announcing routes labeled with
64497:13:0 (blocking all distribution by default) and 64497:14:64505,
64497:14:64506 to instruct the route server to force announcement to
those two ASNs.
5. Security Considerations
Operators should note the recommendations in Section 11 of BGP
Operations and Security [RFC7454] and handle BGP Large Communities
with their ASN in the Global Administrator field similarly.
In particular and in the same respect as BGP Communities [RFC1997],
operators should be congnizant that any Large Community can be
carried in a BGP UPDATE. Operators should recognize that BGP
neighbors, particularly customers and customers of customers, may
utilize communities defined by other BGP neighbors of the operator.
They may wish to send routes with action communities and receive
routes with informational communities to or from these other
neighbors and it is beneficial to all to permit this.
6. IANA Considerations
None.
Snijders, et al. Expires October 21, 2017 [Page 12]
Internet-Draft Use of BGP Large Communities April 2017
7. Acknowledgments
The authors would like to gratefully acknowledge the insightful
comments, contributions, critique and support from Adam Chappell,
Jonathan Stewart, Greg Hankins, Nick Hilliard, Will Hargrave, Randy
Bush, Shawn Morris, Jay Borkenhagen and Stewart Bryant.
8. References
8.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017,
<http://www.rfc-editor.org/info/rfc8092>.
8.2. Informative References
[RFC1998] Chen, E. and T. Bates, "An Application of the BGP
Community Attribute in Multi-home Routing", RFC 1998,
DOI 10.17487/RFC1998, August 1996,
<http://www.rfc-editor.org/info/rfc1998>.
[RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264,
DOI 10.17487/RFC4264, November 2005,
<http://www.rfc-editor.org/info/rfc4264>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
"Internet Exchange BGP Route Server", RFC 7947,
DOI 10.17487/RFC7947, September 2016,
<http://www.rfc-editor.org/info/rfc7947>.
[RFC7948] Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker,
"Internet Exchange BGP Route Server Operations", RFC 7948,
DOI 10.17487/RFC7948, September 2016,
<http://www.rfc-editor.org/info/rfc7948>.
Snijders, et al. Expires October 21, 2017 [Page 13]
Internet-Draft Use of BGP Large Communities April 2017
8.3. URIs
[1] https://www.nanog.org
[2] https://nlnog.net
[3] https://www.iso.org/iso-3166-country-codes.html
[4] https://unstats.un.org/unsd/methodology/m49/
Authors' Addresses
Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
The Netherlands
Email: job@ntt.net
John Heasley
NTT Communications
1111 NW 53rd Drive
Portland, OR 97210
United States of America
Email: heas@shrubbery.net
Martijn Schmidt
i3D.net
Rivium 1e Straat 1
Capelle aan den IJssel 2909 LE
NL
Email: martijnschmidt@i3d.net
Snijders, et al. Expires October 21, 2017 [Page 14]
