The end > sites are demanding autonomy with a stable routing system. That set of > requirements leads to structured allocations and topology constraints. ...it should be noted that the ones holding the money are the end sites. Which makes a case for concentrating the effort on a stable routing serving autonomous end sites. Frankly paying for an IP address makes as much sence as buying a street address (how about the Post Office putting hot street addresses on sale). It appears that IP address assignment reaches far and beyond Internet engineering and should be administered by the international politically / economically independed structure guided through RFC. peter@xxxxxxxxxxxxxxxx --- Tony Hain <alh-ietf@xxxxxxxx> wrote: > 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 > > addresses. > > 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 > between cities). > > > > > > > PS: > From: Kevin Loch <kloch@xxxxxxxxxx> > > > > > I find this comment extremely offensive. ... Your implication that > > the > > > 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 > > considered > > 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 > > an > > engineering decision to deploy PI-space. It's hard to read that decision > > any > > other way than to have it imply that the decisions in those WG's were > > technically uninformed. > > 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. > > Tony > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf