Internet DRAFT - draft-li-int-aggregation
draft-li-int-aggregation
INTAREA Working Group Tony. Li
Internet-Draft Juniper Networks
Intended status: Best Current Practice 31 January 2022
Expires: 4 August 2022
On Higher Levels of Address Aggregation
draft-li-int-aggregation-00
Abstract
Routing and addressing are inexorably tied, and the scalability of
the routing system is wholly dependent on the abstraction and
allocation of the address space. The addressing architecture for the
Internet was set forth in [RFC1518], [RFC4632], and [RFC4291]. These
describe how address aggregation can be performed at the ISP and
local level.
Address allocation and assignment procedures by the Regional Internet
Registries (RIRs) have created large address blocks. This creates an
opportunity for further aggregation above the ISP level without any
change to existing allocations.
This document discusses issues regarding address aggregation above
the ISP level, for continents or regions, thereby providing
additional address space aggregation and efficiency in the routing
system. Small changes to address allocation policies can help to
ensure futher aggregations and improvements in routing efficiency.
Some of these concepts were discussed as part of the Routing and
Addressing meetings [RFC1380] and extended further here.
This document is not advocating geographical assignment below the
continental level. That has been thoroughly discussed previously.
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 https://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."
Li Expires 4 August 2022 [Page 1]
Internet-Draft On Higher Levels of Address Aggregation January 2022
This Internet-Draft will expire on 4 August 2022.
Copyright Notice
Copyright (c) 2022 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Routing and Addressing . . . . . . . . . . . . . . . . . . . 3
4. Abstraction and Aggregation . . . . . . . . . . . . . . . . . 4
5. Abstraction Boundaries . . . . . . . . . . . . . . . . . . . 4
6. Regional Aggregation . . . . . . . . . . . . . . . . . . . . 6
7. Continental Aggregation . . . . . . . . . . . . . . . . . . . 8
8. ICANN Considerations . . . . . . . . . . . . . . . . . . . . 8
9. RIR Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. ISP Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . 9
14.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The Internet depends upon the efficiency and scalability of the
routing system. Without effective routing, no traffic can be
delivered. Ensuring that routing scales is key to the Internet
architecture. History has shown that the architectural changes made
as part of [RFC1518] and [RFC4632] have been extremely effective.
Li Expires 4 August 2022 [Page 2]
Internet-Draft On Higher Levels of Address Aggregation January 2022
However further improvements are possible. While prefix aggregation
at the ISP level has helped provide good routing efficiency, more
aggregation is possible. This document discusses how aggregation
could be performed above the provider level, forming aggregates at
the regional or continental level based on the address allocations
that have already been performed.
This document also suggests ways that ICANN and the RIRs can change
address allocation procedures to enable better future regional and
continental aggregation. These changes would have no perceptible
effect on ISP or end-site address allocations, and would simply cause
the allocations to come from different address blocks from the same
RIR.
IPv4 and IPv6 addresses and prefixes are used throughout this
document as examples. The concepts presented here apply equally to
both address spaces.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Routing and Addressing
The routing subsystem of the Internet is responsible for discovering
paths from any point on the Internet to any other point. The results
of the routing system are paths instantiated in the forwarding plane
of routers throughout the network, resulting in end-to-end
connectivity.
For routing to function, there must be specific names for hosts. The
architecture of the namespace for these names is a critical decision,
as these names will have global scope. When we also use these names
as a binding to a location in the network, we call these names
'addresses' and the namespace that they are taken from an 'address
space'.
Li Expires 4 August 2022 [Page 3]
Internet-Draft On Higher Levels of Address Aggregation January 2022
Scalability is a central concern for routing. Each item of
information that routing must propagate around the network requires
processing power and memory for storage throughout the network. This
scales with the size of the network. If routing also scaled linearly
with the number of hosts, then the cost of running the routing system
would grow as the size of the network times the number of hosts,
which is clearly problematic. For this reason, we cannot have a
routing subsystem that just carries individual host routes.
4. Abstraction and Aggregation
Instead, we seek to define groups of hosts and treat them together as
a single abstraction, commonly known as a 'prefix'. We call the
process of combining addresses together into a prefix 'aggregation'.
Under some circumstances, prefixes themselves may also be aggregated
to form another prefix, resulting in a recursive structure. If
prefix A is a proper subset of prefix B, we say that A is 'more
specific' than B and that B is 'less specific' than A.
We can then define the routing efficiency of a specific prefix as the
cost of carrying that prefix, plus all of its more specifics,
integrated across the entire network, and divided by the number of
host addresses subsumed by the prefix.
It is well known that abstraction obscures important detail and that
abstraction in routing can cause sub-optimal paths, resulting in
extra hops, wasted bandwidth, and managerial difficulties. As a
result, there will always be a trade-off between scalability and
optimality when introducing abstractions.
When optimality is paramount and simple reachability is insufficient,
the routing subsystem has additional mechanisms that allow network
operators to make different path selection choices, sometimes
intentionally ignoring or explicitly working against abstraction. We
call this broad set of mechanisms 'traffic engineering'.
5. Abstraction Boundaries
Abstractions have three different boundaries that we will be
concerned with:
Abstraction Administrative Boundary
An abstraction's administrative boundary occurs at the topological
interface between the abstraction's administratively controlled
network and other administrations.
Li Expires 4 August 2022 [Page 4]
Internet-Draft On Higher Levels of Address Aggregation January 2022
Abstraction Naming Boundary
An abstraction's naming boundary is the topological container of
all of the host addresses within that abstraction.
Abstraction Action Boundary
An abstraction's action boundary is the topological container
where the abstraction has an effect on routing's path computation.
In simple cases of abstraction, these boundaries are aligned. For
example, consider a university that has been assigned the prefix
128.125/16. It has a pair of routers that interface to its two ISP's
and it advertises that prefix to both of it's ISPs and no more
specifics. The entire university's infrastructe utilizes this one
prefix. In this case, the administrative, naming, and action
boundary all occur between the university's router's and the ISPs'.
As a more interesting example, consider an ISP X that has been
assigned the prefix 2001:1234::/32. For its own internal purposes,
the ISP chooses to partition this prefix and assigns
2001:1234:5600::/40 to city C, which is an IGP area in the ISP's
network. For traffic engineering purposes, ISP X also advertises
more specifics of the city C prefix to ISP Y, but not to ISP Z. The
more specifics are constrained so that ISP Y cannot propagate them to
its neighbors (e.g., using the BGP NO_EXPORT community).
ISP X
XXXXXXXXXXXXXX ISP Y
XXX XX
ISP Z XX XX
XX X YYYYYYYYYY
XX X YYY YY
ZZZZZZ XX X---YYY YY
ZZ ZZZZ XX X Y YY
ZZ ZZ----XX CCCCCC XX YY Y
ZZ Z XX CC CC X YY Y
ZZ Z X CC CC X------YY YY
ZZZ ZZ X C C XX YYY YY
ZZZZ ZZZ XX C CXX YYYYYYYYY
ZZZZZ X C CCCX
XX CCCCCCCX
XXXXXXXXXX
The administrative boundary for the city C prefix is now ISP X's
entire network. The naming boundary is city C itself, but the action
boundary includes ISP X and Y, but not ISP Z.
Li Expires 4 August 2022 [Page 5]
Internet-Draft On Higher Levels of Address Aggregation January 2022
Placing the abstraction action boundary at an acceptable location is
key. If the action boundary is not located correctly, then it may
allow prefixes to propagate too far, unnecessarily damaging routing
efficiency, or it may not allow prefixes to propagate far enough,
causing traffic to take suboptimal paths.
R1-------R2
| \
| \
| \
| R3-----R6
| /
| /
| /
R4-------R5
In the above figure, suppose that prefix A is advertised by router R1
and prefix B is advertised by R4. If aggregation is performed at
router R6, then that is inefficient. Router R3 is the next hop for
both prefix A and B, so if R3 had aggregated A and B, R6 would have
less state to carry. Conversely, if aggregation happened at routers
R2 and R5, then R3 would likely make a suboptimal forwarding
decision, possibly sending traffic for prefix B via R2 instead of the
optimal R5.
From this, we can see that the perfect location for the action
boundary is the first point where all paths would merge. For
pragmatic reasons, it's easier to put action boundaries at
administrative boundaries. Thus, the optimal action boundary would
be the network boundary after the path merge point.
6. Regional Aggregation
Abstraction can be used to help aggregate routing information above
the ISP level, as well as below. While this is currently not
commonly done, it should be considered as a means of further reducing
the size of the global routing table and improving routing
efficiency.
Address allocation today is performed at the behest of the Internet
Assigned Numbers Authority (IANA), currently delegated to five
Regional Internet Registries (RIRs): AFRINIC, APNIC, ARIN, LACNIC,
RIPE NCC. Those registries are assigned large blocks of address
space that they in turn assign to ISPs and other networks. We can
take advantage of the topological connectivity within a region and
consider aggregation across ISPs.
Li Expires 4 August 2022 [Page 6]
Internet-Draft On Higher Levels of Address Aggregation January 2022
Current address allocation policies have given each RIR a number of
address blocks. While aggregation of these blocks is not a
requirement, they are a convenient starting point. Any ISP can look
at their routing table and determine whether or not they are within
the optimal abstraction boundary of such a prefix. If not, then that
prefix is good candidate for aggregation by the ISP.
While the ISP could aggregate the prefix on routers where it would be
advertised to other ASes, it might be more beneficial if the ISP
performed the aggregation on the routers where the more specifics
enter the network. This saves the ISP from carrying the more
specific prefixes internally, which is an economic incentive to
aggregate.
There are several important considerations when contemplating this.
Since more specifics are not carried internally, traffic for the
prefix will find the closest exit point. This is sometimes known as
'hot potato routing'. This may or may not be compatible with the
ISP's routing policy. Aggregation may also cause global traffic
patterns for the prefix to change. Since more specific prefixes are
preferred, if an ISP starts advertising an aggregate to its neighbors
and those neighbors are still receiving more specifics from other
sources, the traffic for the prefix may be diverted away from the ISP
through the more specifics. This may also be in conflict with the
ISP's routing policy. If not, then it may actually be beneficial to
the ISP as they are still offering transit for that prefix, but not
actually carrying any traffic for it. This is another economic
incentive to aggregate.
ISPs that wish to perform this aggregation are able to do so
unilaterally. No coordination with other entities is required,
although prior discussion beforhand might avoid operational issues.
A common traffic engineering practice today is to advertise more
specifics of a prefix today at different entry points with different
path attributes in an attempt to influence inbound traffic patterns.
This has proven very effective and become very common. This is very
harmful to overall routing efficiency because the more specifics
propagate very widely, far beyond their point of actual impact.
Regional aggregation could help to recapture much of this
inefficiency.
Li Expires 4 August 2022 [Page 7]
Internet-Draft On Higher Levels of Address Aggregation January 2022
7. Continental Aggregation
Continental aggregation was previously discussed in [RFC1518].
Today, some RIRs are closely aligned with a continent, so continental
and regional aggregation are aligned. However, for RIRs that serve
more than one continent, there is a natural opportunity for
additional aggregation. Continental boundaries are commonly aligned
with a few very expensive links. In graph theoretic terms, these
links form a natural cut-set, making a continent a possible valuable
abstraction. Since routing across the cut-set is likely to be
expensive, providers will want to optimize it, however, it is also
likely that the optimal abstraction action boundary for a continental
abstraction is just beyond the links in the cut-set.
To maximize the ability to create continental abstractions, RIRs that
serve more than one continent should consider allocating blocks by
continent and delegating from within those blocks to entities within
those continents.
8. ICANN Considerations
The current IPv6 Global Unicast Address Assignments are found in
[v6guaa]. While some hierarchical allocation is being practiced,
there have been numerous blocks allocated that are not aggregatable.
This document recommends that ICANN review their policy on global
address allocation and consider reserving shorter prefixes for RIRs,
such as /4's or /8's, and then making further allocations to the RIRs
from these shorter prefixes. This would, in the distant future,
enable more opportunities for regional aggregation.
9. RIR Considerations
This document recommends that RIRs optimize their address allocation
policies to maximize the opportunities for regional and continental
aggregation.
RIRs that serve more than one continent should consider allocating
address blocks per continent and delegating from those blocks to
providers on that continent.
Allocations to multi-regional providers should be done from separate
blocks than regional providers. This will maximize the opportunity
to aggregate regional providers.
Li Expires 4 August 2022 [Page 8]
Internet-Draft On Higher Levels of Address Aggregation January 2022
10. ISP Considerations
This document encourages ISPs to aggregate more, both to help the
overall routing efficiency of the overall Internet also to help
contain local costs, as well as churn from oscillating more specific
prefixes and accidental deaggregation.
11. IANA Considerations
The author would like to take this opportunity to thank IANA for
years of selfless service. This document makes no further requests
of IANA.
12. Security Considerations
This document creates no new security issues.
13. Acknowledgments
The author would like to acknowledge the contributions of J. Noel
Chiappa to routing architecture in general and for his specific
insights in defining the abstraction naming boundary and the
abstraction action boundary.
14. References
14.1. Normative References
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518,
September 1993, <https://www.rfc-editor.org/info/rfc1518>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
Li Expires 4 August 2022 [Page 9]
Internet-Draft On Higher Levels of Address Aggregation January 2022
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
14.2. Informative References
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, DOI 10.17487/RFC1380, November
1992, <https://www.rfc-editor.org/info/rfc1380>.
[v6guaa] IANA, "Address Family Numbers", November 2019,
<https://www.iana.org/assignments/ipv6-unicast-address-
assignments/ipv6-unicast-address-assignments.xhtml>.
Author's Address
Tony Li,
Juniper Networks
1133 Innovation Way
Sunnyvale, California 94089
United States of America
Email: tony.li@tony.li
Li Expires 4 August 2022 [Page 10]
