Noel Chiappa wrote:
> the desire not to pass a "PI for everyone" policy that would explode
> the routing table.
Interesting that you should mention that, because there's zero technical
differentiation between "PI space" and "portable addresses". So I have to
wonder if this initiative will raise the pressure from users for portable
Depending on how they actually get defined and handed out, portability could
be one outcome. Scott & a few others of us are working on the next step
which would put limits on the extent of that portability (ie: it is
manageable to deal with porting between providers within a city, but not
PS: > From: Kevin Loch <kloch(_at_)hotnic(_dot_)net>
> I find this comment extremely offensive. ... Your implication that
> participants were either uninformed or diddn't care about the
> consequences is completely off base.
There's a certain deep irony here, because PI-addresses have been
at length in the IETF in at least two different WG's - CIDR-D and Multi-6.
Both rejected them after extensive discussion.
Nevertheless, a policy-making body has seen fit to ignore that, and make
engineering decision to deploy PI-space. It's hard to read that decision
other way than to have it imply that the decisions in those WG's were
No, those groups couldn't see the forest for the trees. They were absolutely
technically informed, but completely unwilling to listen to the big picture
political reality. This thread is arguing that this policy decision has the
opposite problem, but in fact it does not. It is an attempt to get in front
of what is a growing wave of demand to head off an outright pronouncement
from outside the community which will result in number portability. By
moving first we can put in enough technical structure to contain foreseeable
problems, while if we wait we will be forced into a quick and dirty random
approach that we all know will fail.
I was not happy with the policy as worded, but willing to live with it for
now as a first step to really fixing the problems facing edge networks. The
locator/id split approach is a nice thing to work on, but it will take more
than a decade to deploy even if people agree to the result. The fundamental
problem is that most of the meager security architecture we do have relies
heavily on those being aligned. If they are split all of the firewall
silicon will have to be rebuilt and new mechanisms for tracking the identity
in flight will have to be developed. Of course none of that work will start
until the non-deployable shim approach has proven itself viable. Add to that
the fact that it moves any semblance of control the ISP thought they had to
the end node and you will find that as they already have said they will do
all they can to block its adoption.
The IETF has consistently refused to acknowledge that prefixes independent
of PA are necessary. The intense focus on maximum aggregation at all costs
is just not viable for end customers. A broken routing system is equally not
viable, but there is a middle ground that gets messy because it does not
have simple solutions without constraining topology. These are all
trade-offs, and the ISPs are demanding unconstrained topology with a minimal
routing table. That set of requirements leads to efforts like shim6. The end
sites are demanding autonomy with a stable routing system. That set of
requirements leads to structured allocations and topology constraints. Both
sides will have to give, but it should be noted that the ones holding the
money are the end sites.
Ietf mailing list