Re: routing around Sprint's depeering damage

From: Matthew Petach (no email)
Date: Sun Nov 02 2008 - 15:14:20 EST

  • Next message: (no name): "Re: routing around Sprint's depeering damage"

    On 11/2/08, Matthew Petach <> wrote:
    > On 11/2/08, Adam Rothschild <asr+> wrote:
    > > On 2008-11-02-10:14:14, Matthew Kaufman <> wrote:
    > > > But seriously, it shouldn't be necessary to have two connections at
    > >
    > > This is less than clear, and largely dependent on a specific
    > > organization's [in]ability to function if their internets go down.
    > > End-site multihoming in some form or fashion is a growing requirement,
    > > and folk thinking otherwise need to get their heads out of sand.
    > >
    > > If anything, these recent de-peerings underscore the lack of wisdom in
    > > end users connecting to (or purchasing CDN services from) members
    > > of the tier 1 club directly.
    >
    >
    > Thank goodness IPv6 cleanly supports end-site multihoming so we
    > won't ever face messy issues like this in the Internet of tomorrow!
    >
    > Oh, wait--could this end up being a damper on IPv6 deployment?
    >
    > "I'd like to move to IPv6, but I can't multihome in IPv6, and I've seen
    > what happens when you don't multihome--so I'll stick with v4, where
    > I at least have the option to multihome to try to avoid being screwed
    > when the net is partitioned like this."
    >
    > Hopefully people recognize that we're rapidly being caught between
    > the twin perils of Scylla and Charybdis here; on the one hand, we
    > don't want to mandate universal connectivity throughout the Internet,
    > we want to allow networks to engage in squabbles like this, and we
    > tell companies "hey, this is the reality of the internet--you want your
    > customers to have more reliable connectivity, you need to multihome"
    >
    > But at the same time, we're telling them "IPv4 is running out, you need
    > to look at moving to IPv6; oh, by the way, in IPv6, you don't get to
    > multihome, you get your addresses from your upstream, and you're
    > stuck with them; you can buy from multiple upstreams, but you'll
    > have to use some type of kludge to switch addresses to make use
    > of the additional paths."
    >
    > With network partitioning becoming more and more an accepted
    > fact of the Internet, if multihoming in IPv6 is not made at least as
    > easy as it is in IPv4, companies who cannot get PI space will not
    > move to IPv6 for any serious production traffic; they have heard us
    > chant the "you must multihome in order to reach the entire Internet,
    > partitions happen on a regular basis, and we refuse to let anyone
    > put regulations in place to prevent them" mantra enough times to
    > realize that the only viable business model for the forseeable
    > future is to use IPv4 addresses in an end-site multihomed fashion.
    >
    > This is the bed we have created for ourselves; why do we spend
    > so much time here wailing and wishing it were otherwise?
    >
    > Matt

    And, just to converge one more set of threads together, including
    the recent talk at the NANOG in LA; for those of you complaining
    about routing table explosion, who are having to take steps to filter
    out routes so that your table still fits in the 256K memory slots your
    current kit affords, and for those who are panic-stricken over the
    thought of having to upgrade all your routers in case we allow
    multihoming in IPv6--it is events like this that drive the message
    home that multihoming is a requirement even for smaller businesses
    in order to stay well connected in the Internet of today; and it is a
    result of this drive for ever-smaller entities to be multihomed that
    will drive up routing table size, and force networks to upgrade
    their routers.

    So--don't want to be forced to upgrade your routers? Perhaps
    mandated interconnection arrangements might not seem so
    terrible to your management, if it means you can save millions
    on capex for router upgrades.

    I think it's only a matter of time before we're forced to choose
    between shutting up and doing forced technology refreshes
    across wide swaths of the internet to support the swelling
    routing tables that are the direct result of additional multihoming
    due to events like this (which I'm sure will make the router vendors
    quite happy), or accepting mandated interconnection and universal
    connectivity requirements which will keep the routing table size
    down, as people won't have the same pressures forcing them to
    multihome, and will let them contemplate moving to IPv6 without
    fear of being partitioned (which I'm sure will make the smaller
    businesses happier, as well as the network engineers who will
    no longer have quite the gun pointed at their head forcing memory
    upgrades of all their router kit).

    Personally, I'm betting on the latter outcome, as much as I don't
    like it. Governments seem to be unable to resist getting involved
    whenever it seems that some fundamental linchpin of their society
    is at risk of faltering or failing without intervention. And unfortunately,
    I've not seen anyone offer a solution yet that solves all the issues:
    1) Prevent or address partitioning of the internet due to depeerings
    2) Provide reasonable assurances to end sites of near-universal internet
         access, barring reasonable outages, maintenance periods, etc. without
         the need for all end-sites to multihome to multiple upstream providers
    3) Provide a reasonable migration path to IPv6, either by re-drafting the
         IPv6 addressing guidelines to allow widespread end-site multihoming,
         or by providing assurances that single-homing will not lead to long-term
         widespread network partitionings due to depeerings or other disputes
    4) Limit the potential explosion of routing table entries and forced technology
         refreshes due to the lack of universal connectivity and the
    resulting demand
         for multihoming.

    I'm sure I'm just nearsighted; but I don't see any other way to solve
    the situation other than through regulation. Can someone else help
    enlighten me as to how else we can deal with these converging,
    conflating issues forcing us towards a cliff, before we hit the IPv4
    exhaustion point, and realize that we've backed ourselves into a
    corner and have no choice but to accept regulation--because we
    can't upgrade all our networks fast enough to allow everyone to
    multihome in IPv6, and we're not willing to self-regulate ourselves
    in the IPv6 world to forbid intentional creation of widespread network
    partitions?

    Thanks!

    Matt
    (hoping it's just the lack of breakfast making him paranoid this morning)


  • Next message: (no name): "Re: routing around Sprint's depeering damage"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD