Hi Tony, Here are some comments:
> 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. I suggest instead: In accordance with RFC 2014, the co-chairs have written the following recommendation. > The > remainder of this section describes the rationale and decision of the > co-chairs, and does not reflect the consensus of the group. OK. > 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. This does expand on your use of the term "scalability", as I suggested in (msg06474). However, in that message I raised some questions about your goals which remain unanswered in your current text. > ... grow the routing subsystem This is ambiguous. It could mean adding more routers, or making the routing system do more work, or support more end-user networks with portability, multihoming, TE, mobility etc. ILNP and other CEE architectures do not, in general, "grow the routing subsystem" as it is currently understood. In fact, they do this, by making every host part of the routing subsystem - and by making that subsystem do more work than the current purely network-based (not host-based) "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. OK - but what do you mean by "routers"? If you mean existing and DFZ routers and routers of the future which perform the same roles, then this requirement is met perfectly well by the Core-Edge Separation architectures such as LISP, Ivip and IRON-RANGER. (It may also be met by CEE architectures such as GLI-Split, ILNP, Name Based Sockets and RANGI - though some of these do involve additional router functions, which may involve DFZ routers.) The CES architectures add new network elements, some of them which are known as "routers" (ITRs, ETRs or similar roles in IRON-RANGER) - and/or new functionality in existing routers. A CES architecture may involve adding functionality to a DFZ router, but only as a matter of choice for the network which runs that router. In Ivip, there is no need to use existing DFZ routers for ITR functions - so all DFZ routers can remain completely untouched. With Ivip, there may be no need to alter any routers - all the work could be done by new devices, including by all those devices being COTS servers. CES does involve new work being done in the network - by devices which are specifically designed to do this efficiently. In LISP, Ivip and IRON-RANGER (as currently discussed), there is no use of BGP for conveying information between these new devices or new router functions. Each CES architecture has its own way of providing much more scalable communications between the new devices or functionalities which need to communicate - with the intention that they scale well. Both CEE and CES architectures pretty much leave the DFZ routing system alone. CES architectures do not burden hosts at all. They add new things to the network which are designed to cope well with the intended massive growth in adoption of portability, multihoming, TE and mobility. CES architectures work fine for IPv4 and IPv6. CEE architectures either do not add anything to the routing system or add what is argued to be less to it than a CES architecture. CEE architectures burden hosts with all or most of the new work - and they only work by modifying IPv6. They can't work for IPv4 (msg06489 and msg06530). If your goal is to make the Internet endlessly scalable without any architectural additions to the network, then you might be able to do this with CEE - at the great cost of moving every host to IPv6 and then to using new stack and perhaps application software in order to fully implement the new Locator / Identifier Separation naming model. Your recommendation of ILNP doesn't acknowledge anything about the transition and adoption difficulties, or contain any justification for why hosts should do most or all the work (CEE), rather than the network (CES). > 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. I think you need to mention your goals, such as increased access to portability, multihoming, inbound TE, mobility etc. on a scalable basis. Or are you only aiming to provide the currently overly constrained access to these benefits, while limiting the costs this imposes on the existing routing system? > 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. As I mentioned in (msg06474), you do not provide any evidence for this assertion - and I believe many people will not be able to think of any such 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. So you feel no need to solve the IPv4 scaling problem - or to explain to readers why you consider it to be of such low importance. > 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. OK. > 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. Sure - but you haven't explained to readers why hosts should do the extra work, why CES approaches are more trouble or less beneficial than CEE approaches, or why you chose ILNP over the other CEE architectures: GLI-Split, Name-Based Sockets and RANGI. > 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. The fact that ILNP (or other CEE architectures) have a much more onerous set of barriers to adoption than CES architectures doesn't mean they are a better solution in the long-term. > 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. Yes, but a CES architecture can provide immediate benefits to all adoptors, and routing scaling benefits in direct proportion to the level of adoption. So you don't need any short-term things to go along with CES. ILNP and other CEE architectures at the very best might take decades to be widely enough deployed that most communications will use the new system. > 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, Its not the charter - it is according to the IRTF rules which enable the chair a great deal more choice in how the work will be done than in an IETF WG, which many readers will not understand. > 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. For my critique of these rationales, please see: http://www.ietf.org/mail-archive/web/rrg/current/msg06441.html http://www.ietf.org/mail-archive/web/rrg/current/msg06474.html and for what I think would be a good recommendation: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
