Hi all,
Here's the next pass at section 17. Please comment.
Regards,
Tony
--------
17. Recommendation
As can be seen from the extensive list of proposals above, the group
explored a number of possible solutions. Unfortunately, the group
did not reach rough consensus on a single best approach.
Accordingly, the recommendation has been left to the co-chairs. The
remainder of this section describes the rationale and decision of the
co-chairs, and does not reflect the consensus of the group.
As a reminder, the goal of the research group was to develop a
recommendation for an approach to a routing and addressing
architecture for the Internet. The primary goal of the architecture
is to provide improved scalability for the routing subsystem.
Specifically, this implies that we should be able to continue to grow
the routing subsystem to meet the needs of the Internet without
requiring drastic and continuous increases in the amount of state or
processing requirements for routers.
17.1. Motivation
There is a general concern that the cost and structure of the routing
and addressing architecture as we know it today may become
prohibitively expensive with continued growth, with repercussions to
the health of the Internet. As such, there is an urgent need to
examine and evaluate potential scalability enhancements.
For the long term future of the Internet, it has become apparent that
IPv6 is going to play a significant role. It has taken more than a
decade, but IPv6 is starting to see some non-trivial amount of
deployment. This is in part due to the depletion of IPv4 addresses.
It therefore seems apparent that the new architecture must be
applicable to IPv6. It may or may not be applicable to IPv4, but not
addressing the IPv6 portion of the network would simply lead to
recreating the routing scalability problem in the IPv6 domain,
because the two share a common routing architecture.
Whatever change we make, we should expect that this is a very long-
lived change. The routing architecture of the entire Internet is a
loosely coordinated, complex, expensive subsystem, and permanent,
pervasive changes to it will require difficult choices during
deployment and integration. These cannot be undertaken lightly.
By extension, if we are going to the trouble, pain, and expense of
making major architectural changes, it follows that we want to make
the best changes possible. We should regard any such changes as
permanent and we should therefore aim for long term solutions that
position the network in the best possible position for ongoing
growth. These changes should be cleanly integrated, first-class
citizens within the architecture. That is to say that any new
elements that are integrated into the architecture should be
fundamental primitives, on par with the other existing legacy
primitives in the architecture, that interact naturally and logically
when in combination with other elements of the architecture.
Over the history of the Internet, we have been very good about
creating temporary, ad-hoc changes, both to the routing architecture
and other aspects of the network layer. However, many of these band-
aid solutions have come with a significant overhead in terms of long-
term maintenance and architectural complexity. This is to be avoided
and short-term improvements should eventually be replaced by long-
term, permanent solutions.
In the particular instance of the routing and addressing architecture
today, we feel that the situation requires that we pursue both short-
term improvements and long-term solutions. These are not
incompatible specifically because we truly intend short-term
improvements to be completely localized and temporary. As the long-
term solution is rolled out and gains traction, the short-term
improvements should be of less benefit and can subsequently be
withdrawn.
17.2. Recommendation to the IETF
The group explored a number of proposed solutions but did not reach
consensus on a single best approach. Therefore, in fulfillment of
the routing research group's charter, the co-chairs recommend that
the IETF pursue work in the following areas:
Aggregation in Increasing Scopes [I-D.zhang-evolution]
Identifier/Locator Network Protocol (ILNP) [ILNP Site]
Renumbering [I-D.carpenter-renum-needs-work]
17.3. Rationale
We selected Aggregation in Increasing Scopes because it is a short-
term improvement. It can be applied on a per-domain basis, under
local administration and has immediate effect. While there is some
complexity involved, we feel that this is option is constructive for
service providers who find the additional complexity to be less
painful than upgrading hardware.
We recommended ILNP because we find it to be a clean solution for the
architecture. It separates location from identity in a clear,
straightforward way that is consistent with the remainder of the
Internet architecture and makes both first-class citizens. Unlike
the many map-and-encap proposals, there are no complications due to
tunneling, indirection, or semantics that shift over the lifetime of
a packets delivery.
We recommend further work on automating renumbering because even with
ILNP, the ability of a domain to change its locators at minimal cost
is fundamentally necessary. No routing architecture will be able to
scale without some form of abstraction, and domains that change their
point of attachment must fundamentally be prepared to change their
locators in line with this abstraction. We recognize that
[I-D.carpenter-renum-needs-work] is not a solution so much as a
problem statement, and we are simply recommending that the IETF
create effective and convenient mechanisms for site renumbering.
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
