Hi Ran and Eliot, I support what you wrote:
>> 2) More General RG Consensus >> >> Noting that "rough consensus" is very different from unanimity, >> I *believe* (could be wrong) that there were a small number >> of conceptual things that the RG did achieve rough consensus >> on. I'd like to see those noted as RG consensus items in >> the Recommendation document. > > +1. +1. >> I think one of those rough consensus items is: >> The Internet continuing down the current architectural path, >> whereby site multi-homing increases the size/entropy of the >> DFZ RIB/FIB is not believed to be scalable or viable. > > +.98. Perhaps I would write it slightly differently. > > The Internet continuing down the current architectural path, > whereby site multi-homing increases the size/entropy of the > DFZ RIB/FIB exposes operators to risks of unpredictable > growth in associated costs. +1 for Eliot's revised version. However, we should probably also add something about concerns regarding less stability, longer convergence times and perhaps security in the interdomain routing system (DFZ). > This takes into account Geoff's latest observations and analysis with > regard to table growth. I don't think we can say at this point whether > things have momentarily leveled off, or whether we are seeing a sort of > plateau, based on current usage patterns. > > I think there is a related point to capture: > > The limits of scaling we see today have led us to impose limits on growth > such as making multihoming far more the exception rather than the rule > and hence limiting means of resiliency. Further, those few consumers who > want to multihome must either pay an inordinate fee for the service, or > must make use of NATs that pose their own sets of problems. +1. Does this sufficiently capture our belief (I think we all believe it) that the number of networks with multihoming (portability and TE too?) today is much smaller than the number which would, ideally, have it? I think most or all of us believe a scalability solution should not only cope with growth in multihoming with the current constraints and costs, but should also greatly reduce those constraints and costs to allow many more networks to do it? >> I think another comes from RFC-4984, specifically from 7.2, >> which suggests some form of ID/Locator split is desirable. >> >> (NB: While the RG does not agree on the details of how that split >> best should happen, there appears to be rough consensus within >> the RG that some form of ID/Locator split is desirable.) Please see my recent message "Separating location and identity - what does this mean?". - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
