I-D Action:draft-azinger-scalable-addressing-00.txt

[Tony Li]

Hi David,

> As I believe others have pointed out, there now exist forums in which address allocation policy is intensively discussed.  Those forums have already voted with their feet against exactly what this draft recommends. I guess I don't see what value this draft is going to bring if it progresses to BCP -- have the RIRs given the slightest indication they will revise their policies to match the recommendation?  In the past, I believe all of the RIRs have indicated they will do what their members tell them to do.  Is the theory that this draft (as a BCP) will convince the RIR members to reverse their decision? 


Well, as we point out in the draft, the RIRs indirectly work for the IETF.  They are obliged to work within the architecture that IETF lays out.


> As to my recommendation on how to proceed, I believe we need to deal with reality as it is.  Reality is that enterprises prefer PI to PA for sound business reasons. One approach forward appropriate for the IETF would be to identify and attempt to address those business reasons within the current architectural constraints (RFC 5887 is one step in that direction).


The IETF doesn't pretend to be involved in economic issues, as you well know.


> Another way forward for the IETF would be to revise the architecture (see RRG, LISP, ILNP, etc).


Those are in progress, as you well know, but none of our work has yielded anything that appears to be vaguely miraculous.  In fact, if anything, it all seems to have fairly long term effects.  Given that the problem is now, and even most of the long term solutions require effective, strong aggregation, we need to start moving in that direction.


> Another way forward for the IETF (or somebody) to identify where the actual pressures are in routing system growth (TE?, PI?, multi-homing?, spurious deaggregation?) and try to address those specific pressures (See GROW).


Those pressures have been enumerated already.  Within the v6 space, PI appears to be a substantial contributor.  Thus, our proposal.


> But you know all this.


And you know full well that I've been at the forefront of driving this for a very long time.


> Pragmatically speaking, I guess I believe the right answer would be to refer the authors to the RIR public policy mechanisms (and trust me when I say you have no idea how ironic me making this statement is). As I learned in the post-2050 IRE days, the IETF isn't the best venue to try to discuss address policy.


Again, we're not here to discuss policy.  Our point is about architecture.  Policy decides who qualifies for what role.  Architecture is deciding how the technical pieces must be put together to scale.


> Are you expecting a different result? (see Albert Einstein's quote).  It isn't a band-aid.  It is King Canute waving his hands at the tide.


Actually, the aggregation that we put in place in 1992 was significantly effective.  It's not sufficient, but in terms of reducing the growth rate and keeping the table manageable, it has been successful.  It is certainly preferable to the unconstrained growth that we saw prior to aggregation.


> I (as I believe you too) have heard well known router vendors get up in public venues and state there is no immediate routing scalability problem and that they can handle FIBs of 10,000,000 entries today (who am I to dispute these assertions?).  


There is no immediate global warming problem, either.

You might also ask those same routing vendors what their BGP convergence times for those situations are.  ;-)  


> According to the projections in the draft, this means today's technology can support routing table loads projected in (call it) 2027. 17 years. Remember what things were like in 1993?  From my perspective, there appears to be a disconnect here.


First, those are NOT projections.  We do not have nearly enough data to extrapolate a meaningful rate.  The data that we have is effectively a single point: 2009.  We present the impact of that rate, so that people understand the qualitative issues at hand, but we cannot reasonably suggest that that is necessarily the outcome.


> Don't get me wrong, as you may be aware, I think routing scalability is a significant issue that needs to be addressed. I just don't see how having the IETF attempt to dictate allocation policy (e.g., "In addition Internet Registries should severely limit or eliminate the amount of PI assignments in order to help facilitate the decrease in routing table growth.") is going to be effective.


Our goal is to put strong aggregation into effective practice.  If we can't do that, then v6 is already dead.  It's IETF's job to put into place the Engineering to ensure that v6 does scale.  We're trying to help do that.

Regards,
Tony