Dear Eliot, all, I'm not sure that splitting the reco document into two files makes sense since the purpose was to come up with a recommendation..which is the case despite that this recommendation is not a RRG consensus but a proposal from the chairs (their proposed text is clear on this). I personally like to have more text to argue how the proposed solutions solve the problem to be solved and what are pieces of the puzzle which need more work. I sent an email to Tony with my comments on the first version of the reco text.
As for your question, I think that the recommendation document in its current state does not provide answers to several (pending) issues such as the following ones: - The proposed solutions I read, imho, seem to not solve the scalability issue since the full table should be maintained in some nodes and this table is not reduced (in transit border routers for current BGP deployment, in TIB tables in TIDR proposal, APR for AIS, LISP/Ivip maintain separate database to store the mapping but still there is a impact on the global routing table in early deployment stages since IDs need to be routable at least to be reached from non LISP/Ivy sites, etc.). These nodes need to be upgraded regularly not only to meet bw increase demand but the increase of the routing+forwarding states. - Can the scalability issue be solved without revisiting interconnection (business) models? - Can the scalability issue be solved without close collaboration with registry bodies (some of the aggregation issues are due to disjoint blocks, this will be even aggravated in the next period due to IPv4 address depletion)? - Can the scalability issue be solved without any firm policy on the use provider independent prefixes/addresses? - To what extent a loc/id solution can mitigate/solve the routing scalability issue? And other open questions related to having a consensus on the problem statement: - Why draft-narten is not acceptable as a starting point to sketch the problems to be solved? A frozen version of the problem statement is must for the group in order to help selecting solution(s). - Unlike the multi-homing case which is obvious, need to motivate why mobility is an issue for routing systems. - How AIS/INLP solve these problems. At least for me, it is not clear how AIS/ILNP solves the routing scalability issue. ILNP concept and DNS documents are silent on IPv4 scenario except the definition of the L32 record but without any further explanation. As for the next steps: - Why not considering launching several experimental effort to assess the validity of proposed approached: in particular AIS and ILNP Suite since this is the recommended solutions by the chairs. Does this make sense? Cheers, Med ________________________________ De : [email protected] [mailto:[email protected]] De la part de Eliot Lear Envoyé : vendredi 23 avril 2010 11:34 À : Tony Li Cc : IRTF Routing RG Objet : Re: [rrg] Next pass Tony, I think this looks pretty good. Vince, Heiner, and Hongbin have suggested that the document be split. That's an interesting idea as far as it goes, but one could argue that the best approach would be to not split into two documents, but instead into perhaps one or two per approach, thus providing for a means of evolving the understanding of each approach independently. On the other hand, this has somewhat to do with where the RRG goes from here. If people just want to be finished, then I really don't care how many documents there are, personally, since none are going to evolve, and as Joel points out, the views of the chairs are clearly indicated as their views. And so the question I have is this, and I asked it in the Anaheim meeting (this isn't meant as a question only for Tony): What do people want to do next with this group? Eliot On 4/22/10 10:55 PM, Tony Li wrote: 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]<mailto:[email protected]> http://www.irtf.org/mailman/listinfo/rrg ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
