Hi Phil,
Thanks for the comments. Sorry I couldn't respond sooner.
{ 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.
[phil] I don't agree with this. just because pairwise charging hasn't
happened yet, doesn't mean it couldn't happen.
Well, in some sense you're right, it could happen. However, without a
clear driver and without some evidence of it moving forward, we've got
no reasonable argument that it will happen. Oh, and this is after
several folks have tried to get this started. I don't think we should
wait for this.
While prefix announcement /routing messages can be supported (because
system scales well enough) then there is limited incentive to do it.
ISPs get money from transporting data. If isps hit scaling limit that
affected their ability to transport data & thereby gain money, then
charging for routing msgs would be an option.
We've hit scalability limits repeatedly, since near the start of
operations of non-NSF backed ISPs in the early 90's. It's never been
sufficient motivation for any of them to try charging.
{ > 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.
[phil] something like: Strategy E does not seek to make the routing
protocol more scalable, rather the limited 'capacity' is allocated
according to willingness to pay.
How about just removing the entire paragraph? This is supposed to be a
section on criticism, not advocacy.
{ > 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).
[phil] my point was the strategy e & f don't seem to say anything about
manual locator assignment. Since neither of them develop a new RRG
protocol, they kind of self-exclude themselves from developing an RRG
protocol(?)
Fair. I've removed both from that paragraph. I'll add another section
on the scope of the charter and reference how those strategies aren't
covered by our charter.
Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
