Tony Li allegedly wrote on 04/22/2010 16:55 EDT: > > Hi all, > > Here's the next pass at section 17. Please comment.
Hi Tony. First, a lot of this is general comments on goal, motivation and problem statement. This should all be put up at the front, as context. I would have the order in front be Introduction, then Problem Statement, then "Proposals" with "Abbreviations" being the first subsection under that. For each of your justification paragraphs, I think you should have a summary bullet, e.g. "must be applicable to IPv6", "must be good for the long term". > 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. Ha ha ha. "Incremental" isn't just about new things coming in, it's about old things going out as well. The text should note that the short-term tweaks will be with us for a long time, but that they are necessary steps. When you get down to specifics later, explain why having the short-term tweaks hang around isn't a terrible problem. > 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] Brian's right, renum-needs-work is not a solution, it's a discussion. I would mention it in the "Rationale" as something that helps make ILNP more feasible in the long term, but not up here where you're talking about "solutions". > 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. Here's where you explain why it's okay if people do this for 20 years. > 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. "Clean" etc. doesn't say much -- you should be less subjective. In what ways is it cleaner? Why specifically are tunneling and indirection considered problems? > We recommend further work on automating renumbering because even with Here's where you mention renum-needs-work as a focal point for this important effort, but skip the last sentence -- it's unnecessary since you are no longer presenting it as a solution. > 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. Finally, I recommend a new section: A bulleted list of issues the IETF needs to consider in order to turn this recommendation into real engineering for real networks. I think that would help the IETF figure out what to do with this recommendation. I'll try to contribute to that next but as you have seen I don't have a lot of time these days. Oh, and I appreciate all the work you're doing. Scott _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
