Hi Phil,
Thanks for the comments.
[email protected] wrote:
the S3.3 Herrin taxonomy highly compresses a lot of options. i can
understand the reason for trying to do it very succinctly, however a
couple of things might help without decompressing it: [1] some
figures to illustrate differences schematically [2] an appendix with
some mapping of 'well known rrg protocols' to particular options - ?
I'd welcome the figures. Please note that we're confined to ASCII art
here, so they will require some careful crafting.
I'm trying to stay away from citing the particular proposals, as this
will then easily degenerate into arguments about how each proposal in
turn is not properly represented.
i disagree with Criticism 1 of strategy E (let economics suppress
growth). you say that it needs a central authority system whereby
money is transferreed from ISPs announcing prefixes to ISPs running
core routers. i think that only pairwise interactions are needed ie
just between 2 ISPs that are connected. so ISP-provider charges its
ISP-customer for prefix announcements, this can depend on how
aggregated teh prefix is. the same thing can be done at higher levels
of the hierarachy. the decision whether to charge like this can all
be done independently for every ISP pair. in fact you could argue
that this is already being done today to some extent. [1] route flap
damping limits how often ISP accepts route announcements. you could
view this an economics: no charge if within RFD limit; infinite
charge if over RFD limit. [2] ISP can select who gets PI addresses,
depending on value /payment from customer.
Well, if it only took pairwise charging to make this happen, then it
would seem likely that some ISP would have been willing to start doing
this in a significant way and then these costs would have been passed
down to the consumer. Similarly, if some ISP could start doing this,
then its competitors would also have to move in this direction and
charging would also have become ubiquitous.
Instead what we see is that ISPs accept all routes from any of their
customers simply to protect their bandwidth revenue. Thus, to instill
any feedback mechanism, there's going to need to some centralized
authority that can effectively force a non-zero cost on prefix injection.
Note also that this can't be done by a small group of ISPs due to
anti-trust issues.
something on the lines of the second criticism seems ok, although
"giving up a solution that genuinely enables users" seems rather
provocative /vague [sorry, no text suggestion at the moment]
Granted. I'd welcome alternate word-smithing.
In the conclusions i dont understand what you mean by :
"Further, variants of Strategy B (Section 3.3.2
<http://tools.ietf.org/html/draft-irtf-rrg-recommendation-01#section-3.3.2>
) that require manual locator assignment are similarly unacceptable,
as are solutions that do not significantly change existing host
behavior, such as Strategy D (Section 3.3.4
<http://tools.ietf.org/html/draft-irtf-rrg-recommendation-01#section-3.3.4>
), Strategy E (Section 3.3.5
<http://tools.ietf.org/html/draft-irtf-rrg-recommendation-01#section-3.3.5>
), Strategy F (Section 3.3.6
<http://tools.ietf.org/html/draft-irtf-rrg-recommendation-01#section-3.3.6>
), and Strategy G (Section 3.3.7
<http://tools.ietf.org/html/draft-irtf-rrg-recommendation-01#section-3.3.7>
)." this says that a solution is only accepatble only if it
significantly changes host behaviour. i presume you mean the
opposite. however Strategy E (economics) & F (do nothing) seem to
have no impact on host behaviour either.
The point that I'm trying to make here is that we want to avoid manual
renumbering. This basically means that we have to automate renumbering
or obviates the need for it.
Let me try to word-smith that:
Further, variants of Strategy B (Section 3.3.2) that require manual
locator assignment are similarly unacceptable, as are other solutions
that require manual locator assignment, such as Strategy D (Section
3.3.4), Strategy E (Section 3.3.5), Strategy F (Section 3.3.6), and
Strategy G (Section 3.3.7).
Better?
Regards,
Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
