Couple of follow-ups in line, sorry for the delay.
Best wishes
phil
{ -----Original Message-----
{ From: Tony Li [mailto:[email protected]]
{ Sent: 29 March 2009 23:27
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email protected]
{ Subject: Re: [rrg] Comments on draft-irtf-rrg-recommendation-01
{
{
{ 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.
Sorry.
{
{ 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.
[phil] I don't agree with this. just because pairwise charging hasn't
happened yet, doesn't mean it couldn't happen.
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. In any case, RFC &
slecting who's allowed PI addresses are already proxies for charging for
prefix announcements, so in fact a crude version of strategy E is
already being followed.
{
{
{ > 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.
{
{
{ > 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(?)
{
{
{ Better?
{
{ Regards,
{ Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
