Subject: [RADIR] comments on section 6

From: "John G. Scudder" <[email-masked]>
Date: Tue, 14 Aug 2007 11:20:17 -0400

Folks,

I've received a number of private comments about section 6 in the  
last few weeks.  I've taken a swag at modifying the section to  
reflect those comments.  First, the revised section, then some  
discussion of the changes.

Also, it looks like I'll have to miss our call again today.  Sorry.

--John

Revised section:

6.  Problem Statement

    As discussed in previous sections, in the current business  
environment
    it may be difficult for ISPs to recover control plane related costs
    created by the growth of the Internet.  The Internet needs a viable
    economic model, and technology needs to be designed with this in  
mind.
    Thus, in the absence of a business model which allows such cost  
recovery,
    there is a need for an approach to routing and addressing that  
fulfils
    the following criteria:

    1.  A party who bears the costs of deploying and maintaining
        the technology should be able to derive benefits from it
        that are sufficient to recover the cost for doing so, and cost
        recovery should not be predicated on universal or even  
widespread
        deployment of the technology.

    2.  Reduces the growth rate of the DFZ control plane load.  In the
        current architecture, this is dominated by the routing, which is
        dependent on:

        A.  The number of individual prefixes in the DFZ

        B.  The update rate associated with those prefixes.

        Any new architecture should take care that overall control plane
        load, including but not limited to the above, is addressed.

    3.  Reduces or holds constant the operational expenses associated  
with
        the control plane.  If a new architecture does increase  
operational
        expenses, it must reduce other (e.g., capital) expenses at least
        enough to compensate.

    4.  Allows any end site wishing to multihome to do so.

    5.  Supports ISP and enterprise TE needs.

    6.  Allows end sites to switch providers while minimizing
        configuration changes to internal end site devices.

    7.  Provides end-to-end convergence/restoration of service at
        least comparable to that provided by the current architecture.

Discussion of specific changes and their rationale:

- The overall document exists within the context of a business  
environment, and much of what it addresses is "tragedy of the  
commons" problems, where network operators are not able to recover  
costs associated with factors which drive the scale of the DFZ.  In  
the document, in effect we are calling for technical solutions for  
these "tragedy of the commons" problems.  I think this is fine but we  
can address the concern (about the document's bias towards a  
technical solution solution) by acknowledging that we're only aiming  
to cover that portion of the problem space.  Modified the prefatory  
paragraph to do that.

- Moved old point #5 to be new point #1.  This is because it really  
seems like the overarching point, all the others could almost be sub- 
bullets.  It could be summed up as saying that the Internet needs a  
viable economic model and that technology needs to be designed with  
this in mind -- which really is the point of this whole exercise,  
isn't it?

- Rewrote old point #5 as new point #1.  Frankly I was OK with the  
old text, but the observation was made that the form given above is  
clearer (instead of relying on what's implicit in the word  
"meaningful" in the old version).  The new version also captures the  
principle of incremental deployability which I think is widely (dare  
I say universally?) agreed to be a sine qua non for any new  
architecture to succeed.

- Rewrote old point #1 as new point #2.  The point here is that we're  
not really concerned exclusively with routing load, but rather with  
control plane load.  It's true that the two are approximately equal  
in the current architecture, but clearly some proposed architectures  
would move load to other control plane elements (e.g. a mapping  
service, either push or pull flavored).

- Added new point #3.  The observation was that reducing routing load  
is beneficial insofar as it controls costs to deliver service.  This  
is presumably through controlling capex.  The further observation was  
that if the approach called for in section 6 were to increase opex,  
that would have to be taken into account also -- if we're considering  
costs, we should take a holistic view.  Although this is kind of  
implicit in (old point #5, new point #1), it seemed worth making it  
explicit.

- Renumbered the rest of the points.

- Added point #7, which should be pretty much self-explanatory.   
There's room to debate the point, but I for one think it's  
reasonable.  Others?

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Aug 2007 12:12:18 -0400

John,

Erik, Jason, Marla, Peter and I were on yesterday's call and here is
where we ended up.

>     environment it may be difficult for ISPs to recover control
>     plane related costs created by the growth of the Internet.  The
>     Internet needs a viable economic model, and technology needs to
>     be designed with this in mind.  Thus, in the absence of a
>     business model which allows such cost recovery, there is a need
>     for an approach to routing and addressing that fulfils the
>     following criteria:

I note that in text below, you bring operational costs (opex) into the
text. In principle, I think we all agree this is a bottom line, but
the document (so far) has not really brought in opex
explicitly. Should it?

Also, the above wording, saying "viable economic model" is pretty
strong words, and probably gets us into trouble if we use it
outright. I.e., I can imagine perfectly viable economic models in
which a small number of very large ISPs operate at Tier 1, and the
barriers to enter are very high because very expensive routers are
needed. Who is to say that isn't "viable"?

We also talked about something the document hasn't explicitely stated
before, but I think we all agree with, and that is that we don't want
the cost of routers (or control plane costs, etc.) to be an
unreasonable barrier to entry for new entrants. In some sense, that is
one way to to set the bar for "acceptable" cost.

"Cost recovery" may also be too strong. 

>     1.  A party who bears the costs of deploying and maintaining the
>         technology should be able to derive benefits from it that
>         are sufficient to recover the cost for doing so, and cost
>         widespread deployment of the technology.

The first part of the sentence is OK, but we suggest dropping the part
after the comma. The latter is a truism and is more of a solution
requirement than part of the problem statement.

Also, here is rewording to make the flow consistent with the other
bullets:

     1.  Provides sufficient benefits to the party bearing the costs
         of deploying and maintaining the technology to recover the
         cost for doing so.

>         load, including but not limited to the above, is addressed.

This one we discussed at length, but felt we needed more input from
you. For one thing, the last line it is getting towards solution
requirements. Also, the terminology "DFZ control plane" is not wording
the document has used before, so if we do use it, we'd need to define
the term and maybe make additional changes throughout the document for
consistency.

Also, presumably, you want to bring opex into this as well? Or is opex
considered part of the control plane load?

>     3.  Reduces or holds constant the operational expenses
>         associated with the control plane.  If a new architecture
>         does increase operational expenses, it must reduce other
>         (e.g., capital) expenses at least enough to compensate.

How about something like:

    The overall cost of building and operating a network that is part
    of the DFZ should not be so high as to effectively exclude all but
    a small number of very large organizationas and provide an
    unreasonable barrier to entry for otherwise qualified entrants to
    the business.

(This wording may need a lot of tweaking, but I think the intent
should be clear.)

>     4.  Allows any end site wishing to multihome to do so.

OK

>     5.  Supports ISP and enterprise TE needs.

OK

>         configuration changes to internal end site devices.

OK

>         least comparable to that provided by the current architecture.

OK.

Thomas