[RADIR] comments on section 6

["John G. Scudder" <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/radir