Re: [RADIR] comments on section 6

[Thomas Narten <[e-mail]>]

John,

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


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

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
>         recovery should not be predicated on universal or even
>         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.
	 
>     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.

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

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

OK

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

OK.

Thomas


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