Re: [RAM] First cut at routing & addressing problem statement

[Peter Sherbin <[e-mail]>]

> invitation for contentious argument about exactly what the numbers  
> should be -- which would seem to be a rathole.

There were at least two reasons for suggesting a quantitative benchmark. 1. The
Earth has a finite surface or more precisely a limited band of interest which
includes the surface plus 20-40km above and 10-20km underneath. Thus it will sustain
only a finite number of routers.

2. The draft says that there are 229,789 routes, that "there will be an increasing
pressure to advertise additional prefixes in the DFZ" and that "the amount of work
needed to maintain paths for a given set of prefixes appears to be increasing". Such
conclusions lead to questions like what is the optimal number of prefixes in DFZ?
what is the relationship between the number of prefixes and the number of paths?
What is the optimal number of entries in RIB/FIB for a particular processor speed?
Having numbers here provide a reference point for the discussion.

There is also a few other questions such as what is the general theory/model of the
Internet? what is the countable unit of the Internet: a node, an interface, an end
point, a bit, all of the above? what are the quantitative relationship between the
Internet units? does the exercise of producing the Internet model belong to IETF?

> Seems like flat-out forbidding any slightest configuration change  
> would be going too far

The strict requirement here protects the site. Ideally there should be no effort at
all for the site to change providers. Please keep in mind that the wire-line
Internet is only an individual case of the more general mobile Internet with end
points moving freely between (relatively) static access points. Which access point
belong to what provider should remain transparent to an end point.

> With regard to statement 5, with what other statements do you think  
> it's redundant?

This one is redundant in a sense that it does not specify the quantity of benefits
and that it seems to be a default assumption in any engineering effort whether IETF
or else.

Thanks,

Peter

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

> Peter,
> 
> Thanks for your comments.  With regard to statement 1, we discussed  
> whether targeted numbers might be worth including but decided in the  
> end not to do so for several reasons.  For one thing, it's an  
> invitation for contentious argument about exactly what the numbers  
> should be -- which would seem to be a rathole.  For another, the  
> supportable values are certainly a moving target, based on the state  
> of the art at any given time.
> 
> With regard to statement 4, I personally think it's OK as written.   
> Surely a proposal which can allow switching with no configuration  
> changes also optimally fulfills "minimizing configuration changes".   
> Seems like flat-out forbidding any slightest configuration change  
> would be going too far, though I think it's clear that forced site  
> config changes are undesirable.
> 
> With regard to statement 5, with what other statements do you think  
> it's redundant?  Note that statement 5 focuses on the alignment of  
> cost and benefit.
> 
> Regards,
> 
> --John
> 
> On Jul 27, 2007, at 1:50 PM, Peter Sherbin wrote:
> > Enjoined reading the statement. Re the "flatter" Internet in 5.1.  
> > since around 2000
> > seemingly there is a trend in changing upstream transit contracts  
> > to peering
> > arrangements. By Q1 2007 in the observed example over 80% of  
> > traffic is routed via
> > peers.
> >
> > Statement 1. Would it be beneficial to define the targeted number  
> > of individual
> > prefixes in DFZ, specify the update rate and then architecture  
> > towards those
> > numbers? E.g. assume 1 AS per each 10,000 sq km of Earth's surface  
> > and 9 routes per
> > AS. It gives about 450K as the maximum number of DFZ entries  
> > providing an idea of
> > the router required processing power.
> >
> > Statement 4. Make it more rigid "Allows end sites to switch  
> > providers without
> > configuration changes to internal end site devices".
> >
> > Statement 5. seems redundant
> >
> > Thanks,
> >
> > Peter
> >
> >
> >
> > --- Thomas Narten <[e-mail]> wrote:
> >
> >> The Routing & Addressing directorate has been working on a strawman
> >> problem statement since Prague. I just submitted our first cut as an
> >> Internet Draft and it's available at:
> >>
> >> http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem- 
> >> statement-00.txt
> >>
> >> We would welcome comments on the document. In particular:
> >>
> >>  - Do folk agree with the problem statement as written, or are we
> >>    missing something fairly fundamental?
> >>
> >>  - Are there other pressures on the routing system that we have not
> >>    listed or described completely?
> >>
> >>  - We intentionally did not include improving mobility as a core
> >>    "problem", as explained in the document. (That doesn't mean we
> >>    don't recognize that some of the solutions under discussion may
> >>    also be applicable to mobility scenarios. Rather, we tend to see
> >>    improved mobility as a possible benefit of certain classes of
> >>    solutions.)
> >>
> >>  - Are there other views of what folk perceive the core routing and
> >>    addressing problem to be?
> >>
> >> Thomas
> >>
> >> _______________________________________________
> >> RAM mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/ram
> >>
> >
> >
> >
> >
> > ______________________________________________________________________ 
> > ______________
> > Get the free Yahoo! toolbar and rest assured with the added  
> > security of spyware protection.
> > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
> >
> > _______________________________________________
> > RAM mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/ram
> >
> 
> 



       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC

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