draft-ietf-v6ops-3177bis-end-sites WGLC

[George Bonser]

> 
> Frankly, I'm hoping for such resistance. We have been trying to
address
> routing table growth, and on the one hand get castigated for not
> solving it and on the other hand being rebuked for making suggestions
> that might help. Maybe at some point the folks that want the problem
> fixed will become interested in allowing the needed changes. We'll
see.

Randy says its ephemeral.  I suppose that depends on one's frame
reference for time.  Does "ephemeral" mean a year, 2 years or does it
stretch to 10 years?

The problem is the technical RFCs are not to dictate routing policy.  I
agree.  The RIRs say they are not tasked to enforce routing policy.
That is true.  The problem is, though, that they should at least be
cognizant of the impact their decisions will have on routing policy and
the operators.  I suppose it is a matter of balance.  For example, say
the multi-homed requirement is removed for a direct /48 assignment.  Now
that is going to greatly reduce the amount of PA space the providers
need and at the same time greatly increase the number of /33 le /48
assignments being made.  And if you start seeing direct /64 assignments
in PI space in addition to the above, it really prevents anyone but
those that can afford the most high end gear with the ability to
dual-stack both protocols.  In fact, direct /48 le /64 single-homed
assignments would make the current v4 growth look tame. Everyone and
their parakeet will be getting direct assignments when they really don't
need to.  There isn't an operational reason for a single-homed site to
need PI space and the consequence of them having one is a greater burden
on the community than the benefit obtained by their having it.

Ultimately it is the operators that decide whether to carry a route or
not but at the same time facilitating routing table explosion greatly
favors the larger operators over the smaller.  The people who can afford
to refresh gear due to a policy decision are going to benefit and
probably support the decision because they will see it as a barrier of
entry to (or death knell of) the smaller competitors or independent
autonomous end users who are doing it themselves today.  

I just disagree with the timing.  Right now isn't the time to explode
the v6 table unless it is the purpose of it to force people to choose
one over the other to speed deprecation of v4.  If one is forced to
choose, which do you choose, the one that is growing or the one that is
at its limit of growth?  That question leads to "well, that depends on
who is on which".  If 80% of my traffic is on v4, v4 wins so I take full
tables with good redundancy on v4 and work with a default on v6 shoved
out to transit until the traffic levels reverse and I turn up v6 peering
again, turn down v4, and shove that to transit.

People just don't seem to be "getting" the problem that is just over the
horizon when all the multi-homed nets that are on v4 suddenly start
announcing themselves on v6.  I would wonder how many v6 direct
assignments the RIRs have made that are still not being announced.  That
would give some idea of how big that coming wave is. That would be a
great number to have available in a monthly email.  Number of v6
assignments and number of those being announced even if only partially.