Hi, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Tony Li > Sent: Tuesday, April 13, 2010 3:36 PM > To: IRTF Routing RG > Subject: [rrg] Proposal for recommendation language > > > Hi all, > > I hope everyone's had a chance to get caught up with their day jobs after > IETF. ;-) > > I would like to start work on the language to go in section 17 > (Recommendation) of our document. As a strawman, I would like to propose > the language below. This would appear (modulo editorial changes) as the > complete text of that section. > > Comments?
Forgive me for stating the obvious (which I know no one else on this list ever does) but it seems to me that an unspoken aspect of all this is the tension between Provider-Aggregated (PA) and Provider Independent (PI) addressing. Strict PA seems to me to be fostering a strong customer dependence on ISPs and an inability to switch to a different ISP easily or to multihome a single IP prefix with multiple ISPs. (Yes, I know that multi-addressing is possible in IPv6.) Strict PI on the other hand seems like a "perfect world" scenario, but it also seems to be the driver that has gotten us into this whole mess surrounding routing scaling issues in the first place. But, how can we give the customers the perceived advantages of PI without locking them into a PA "matrix"? How can we make it so that the ISPs serve the customers instead of the other way around? The IRON-RANGER solution to this is simple; have the ISPs give the customers PA addresses, but then let them use the PA addresses as a springboard into PI. Then, the customer border routers get exposed to PA addresses, but the customer internal networks get to use PI and get to multihome whether or not multi-addressing is also used. So why not have a combined PA/PI scenario instead of strictly one vs the other? Wouldn't that tend to have some bearing on the RRG recommendation? These ideas are not in any way mine originally, as anyone who has followed the exchange between Robin and me can see. Again, apologies if I am stating the obvious as I know no one else on this list ever does. Fred [email protected] > Regards, > Tony > > P.s. The draft is also open for folks that would like to make editorial > changes to their contributions. > > ---------------- > As can be seen from the extensive list above, the group explored a number of > possible solutions. Unfortunately, the group did not reach rough consensus > on a single best approach. Accordingly, the decision of the co-chairs is 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] > > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
