Subject: [rrg] Comments on draft-irtf-rrg-recommendation-01

From: <[email-masked]>
Date: Thu, 26 Mar 2009 21:32:32 -0000

couple of comments on this draft:
 
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 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. 
 
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]
 
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. 
 
best wishes,
phil

---

From: Tony Li <[email-masked]>
Date: Sun, 29 Mar 2009 15:26:30 -0700

Hi Phil,

Thanks for the comments.

[email-masked] 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.

> "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

---

From: William Herrin <[email-masked]>
Date: Sun, 29 Mar 2009 22:38:11 -0400

On 3/26/09, [email-masked] <[email-masked]> wrote:
>  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.

Hi Philip,

You'd have to negotiate with too many different parties to carry your
prefixes. Having your ISP negotiate with it's neighbors such that it's
neighbors will carry the negotiations forward to their neighbors
yields precisely the system we have today, which brings us full circle
to the problem we're trying to solve.

On the other hand, it doesn't require a central authority, only a
central clearinghouse in which all participation is optional and the
participants set the rules of their own participation. I posited such
a system in a moderate amount of detail on the NANOG list some time
last year. Basically, you go to the clearinghouse and post your rates
for various types of carriage of routing slots. Then you search
everybody else's posted rates according to the criteria that you need
in order to get the connectivity you want, and for each of the route
announcements you make, you instruct the clearinghouse that you are
purchasing the package of ISPs and rates that you specified in the
search.

Let me ground that with an example: I have 199.33.224.0/23 multihomed
on the Internet. It's for my hobbies. Today that consumes a routing
slot on every backbone router on the Internet. Maybe it's enough to
authorize Verizon Business to announce 199.0.0.0/8 and then for me to
make arrangements with Verizon Business, each ISP in the AS chain from
me to Verizon Business and all ISPs who do business within the
mid-atlantic states to carry my /23 route. That's still hundreds of
entities, far too many to contact and negotiate with by hand. But with
a clearinghouse to facilitate the negotiation and payment process, I
could have full Internet connectivity while consuming routing slots in
less than a thousand organizations instead of some thirty thousand
worldwide. That would lower the real-world impact from the more than
$6k per slot per year today to maybe a couple hundred dollars -- which
I could easily afford to pay.

> provocative /vague [sorry, no text suggestion at the moment]

The long version of that statement went something like this:

If we're resource-constrained so that we can really only have a few
hundred thousand routing slots in the Internet then the Domino's Pizza
franchise down the street can't be multihomed with two ISPs. There
just aren't enough routing slots to give them away. Over time, the
scarcity of those routing slots will make them more and more valuable
to the point where I can't afford to keep my basement multihomed
either.

This does not empower me as an individual; quite the opposite, I'm
obstructed from consuming the resource for something as trite as my
personal hobbies.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004