Re: Faster 'Net growth rate raises fears about routers

[hardie () equinix com]

Greg,
        Sorry if it seemed that I was misrepresenting your position.
I wanted to take up the specific point made in the previous post about
how flooding small announcements is prevented now, in order to assert
that there are customer desires fueling this and that those must be
handled in proposed solutions.  I did not mean to imply that this was
the sole, or even main, point of your post.
        I fully agree with what I do see as your main point, that if
there were other ways to get the customers the benefits they desire,
that they would not insist on using IP multi-homing.  In addition to
transport layer multi-homing, Bob Moskowitz's HIP proposal
(draft-moskowitz-hip-arch-02.txt) and other architectural proposals
offer longer term potential solutions which deserve serious
consideration.  
        On a second point, though, I have to disagree with you that
short term solutions don't matter in the long term.  There is a strong
urge in the Internet standards community to maintain backwards
compatibility, and that tends to mean that short term solutions
circumscribe the potential long term solutions.  The current work to
get H.323 or SIP across addressing realms is a classic example: NATs
provide a solution to one problem (address space exhaustion), but
break signalling protocols which have to cross the address realm.  The
efforts to fix that problem are circumscribed by how NATs work,
no matter how tortuous the efforts may seem.  

                        best regards,
                                        Ted Hardie
                                

        


> On Tue, 3 Apr 2001 hardie () equinix com wrote:
>
> > The people who prevent the current global routing table from being
> > flooded by /25-/30 announcements are also the people who punch holes
> > in their address space for /24s.  Abha's numbers at the ptomaine BOF
> > clearly show the effect of RIR policies (spikes around /20 and /19),
> > but the bigger effect from my perspective was the spike around /24,
> > created (I presume) by the punches in CIDR blocks that providers make
> > to allow multi-homing.  I haven't seen good numbers for the
> > distribution of punches in a long time, but my limited experience
> > indicates that those punches are being made fairly randomly within the
> > provider's allocated address space.  This means that the bit
> > boundaries don't align and you increasingly have mini-swamps inside
> > providers' /19s and /20s.
> >
> > Why are providers doing this?  Someone is paying them to do it.  
>
>
> I don't argue that multihoming is bad. I argue that we're doing it in the
> wrong place with negitive consequences.
>
>
> > Why are customers spending money on this?  My belief is that they
> > want more say in their own fate.  That may express itself as
> > a desire for redundancy in the case of catastrophic business failures,
> > better ability to express their own routing policies, or a simple
> > worry that they won't get the best price if they have only one supplier.
> > At the core of this, though, is a desire for more control over something
> > that they see as increasingly important to their own fate.  
>
> I agree. However, you can offer even greater control and all the other
> benefits of multihoming without doing it at the IP layer.
>
> Multihoming at the IP later thus breaking aggregation is like dumping
> toxic waste, it cost is largely carried by those not in recept of it's
> benefits or any form of payment.
>
> If we can avoid it while still providing the necessary level of service,
> then we should seriously investigate such opportunities.
>  
> > I think there are various short term work-arounds to the current
> > explosion of paths in the routing tables, and I encourage folks to
> > join the ptomaine mailing list (ptomaine-request () shrubbery net) if
> > they want to contribute to the solution.
>
> Short term is nice, but it doesn't matter in the long run. :)
>
> > But don't try to accomplish
> > it by reducing the ability of the customer to control their own fate.
> > There are real economic pressures out there which will prevent that
> > class of solution from success.
>
> I never suggested that, I suggested investigating alternatives which
> increase customer choice, performance, reliability, and Internet
> scalability and potential measures to make the minor inital cost of
> implimentation more acceptable.
>
> The obvious intrest here is that most network operators would not have
> their customers multihoming at the IP level and thus preventing 
> aggregation and polluting the global routing table is there was another
> way to achieve the same benefits.
>