Iljitsch van Beijnum wrote: > ... > Since this has been coming up from time to time for over a decade, > why not look at it, document the results and be done much faster when > it comes up again and again the following decade, I would think. > That was why I proposed a bof, and will do so again. Noel Chiappa wrote: > ... > Perhaps I'm not understanding your point, but the whole point of my > comment > is that there's no "bright technical line" differentiation between one > size > and another, and we'll inevitably wind up being forced to support the > smallest possible one. > That was my point as well. Given that all uses of PI are as legitimate as any other, the issue boils down to finding a way to bucket the results into manageable pieces that will fit in known routers and protocols. > > Perhaps the IESG's reluctance is because this now turns into something > like > the old (PC-incorrect) joke about the gentleman and the debutante in the > railway - we've already decided what we are, now we're only haggling about > the price (or block-size, as the case may be). > The first step on the path to deciding price is to do the AA thing and acknowledge that there is no single global perception of all possible routes (ie: there are already buckets). Once that is acknowledged, we know the system doesn't collapse in the presence of buckets, so the next step is to decide who plays which role in the scenario. The pragmatist says our job is to find the point of equally shared pain. The ISPs want all the pain to be at the edge, and randomly assigned PI puts all the pain in the middle. There are alternatives to be explored. Iljitsch and I have similar approaches where the basic difference is who gets to decide the blocks and on what frequency they might change. Either will work, but there may be others that a working group should evaluate for their trade-offs. Keith Moore wrote: > > ... > > One could argue that we already have. It's called MPLS... > > sort of. MPLS with globally-scoped tags, and a database of > coarse (think subnet sized) identifer to locator mappings that is > distributed via BGP. border routers look at the destination host > identifier, find the set of locators that correspond to it, and pick > the best locator given current routing conditions. > My point was that the technology exists. Yours is that it is currently deployed and operated in a closed manner. I suspect that the difference was because closed was easier than opening it up to manage a global tag list, and that sufficient motivation would change that. Terry Gray wrote: > ... > It does make me wonder if there is any hope for resurrection of 8+8... > The time for that was before the APIs were defined. At this point it would need to be 6+10 (though the e.g.b. control-mongering ISPs are pushing to reduce the amount of space that a sight can have to make it 7+9), but either way it is nothing more than shim6 being done by the edge routers rather than the end systems. The application wants persistence and the network wants the freedom to randomly over-write bits to improve its efficiency (never mind that the process of deciding and over-writing is inherently inefficient). Given that the application is closest to the end user, the end user doesn't care about efficiency unless they are given quantitative feedback about cost, and the globally distributed cost of a routing slot in a fictitious single routing zone is difficult to define, the winner should be obvious. Tony _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf