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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf