Hi all,
I promised to draft some text including some rationale for the
recommendation. I'm attaching a first draft here.
While I do hope that folks find this clear, I don't expect that everyone
will find this compelling.
Most comments are welcome. In particular comments of the form "I'm not
convinced, try again" of "based on this rationale, you should have picked
proposal XYZ" aren't particularly helpful. Comments (and in particular text
contributions) that a) add points or clarify the message, b) improve the
text either editorially or via wordsmithing, or c) otherwise improve the
tone, strengthen the argument, or clarify the intent are very much welcome.
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.
17.1. Motivation
Without a new routing and addressing architecture, there is a concern
that the cost and structure of the routing architecture as we know it
today would become prohibitively expensive, with repercussions to the
overall growth of the Internet. We need to avoid this and must thus
select some solution and push forward with it.
For the long term future of the Internet, it has become apparent that
IPv6 is going to play a signficant 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 runout 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.
Whatever change we make, we should expect that this is a very long-
lived change. The routing architecture of the entire Internet is a
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 change possible. We should regard any such changes as
permanent and we should therefore aim for long term solutions that
Li Expires October 21, 2010 [Page 61]
Internet-Draft RRG Recommendation April 2010
position the network in the best possible position for ongoing
growth. Our goal should be to make permanent, long-term changes to
the architecture and those changes should be smoothly integrated,
first-class citizens within 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 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 be replaced by long-term, permanent
solutions.
In the particular instance of the routing and addressing architecture
today, we feel that both short-term improvements and long-term
solutions are worthwhile. 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
On behalf of the routing research group, the co-chairs would like to
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
those 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.
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
