|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: multi homing pressure
>> That's the operators' view, but not the customer's. >> The customer wants redundancy. > > That's why SLAs exist. > No... SLAs exist to extract some compensation when the level of service doesn't meet the need. In a mission critical situation, SLAs are pretty worthless. The primary benefit of an SLA is that it (hopefully) provides incentive to the provider to avoid screwing up the service. It doesn't directly do anything to directly improve the service or restore service from an outage. > Many customers would rather not multihome directly, and prefer "set it and > forget it" connectivity. It's much easier to maintain a multi-pipe > connection that consists of one static default route than a pipe to > multiple carriers. The former requires simple physical pipe management, > which can be left alone for 99% of the time. The latter requires BGP > feed, an ASN, and typically much more than 1% of an employee's time to > keep running smoothly. > I've done simple ASN/BGP based multihoming for a number of businesses, and, it can be done on a mostly set-and-forget basis. If you have your upstreams supply 0.0.0.0/0 via BGP and no other routes, and, you advertise your networks, believe it or not, that's a pretty stable configuration. If your upstreams are reasonably reliable, that works pretty well. If not, and, you care about knowing what your upstreams can't reach at the moment, then, you need a full feed and life becomes slightly more complicated. > Obtaining single-homed connectivity from a Tier-2 mostly "outsources" > network support, and small to medium size businesses tend to like that. > It's not the only leaf end solution to the problem, but it's a viable one > (and can be less costly to the rest of the world in turn). > It's also not a complete solution to the problem. Sure, there are a class of customers whose needs that meets. However, because this meets some needs does not mean that it is legitimate to pretend that other needs do not exist. While we're at this, I'll debunk a few common myths: Myth: Renumbering pain is proportional to network size. Fact: Renumbering pain is proportional to the number of devices which need to be touched over which you do not have administrative control. A /16 which is entirely under my control and which is not present in ACL and other entries outside of my control is much easier to renumber than a /24 which contains a bunch of VPN terminators and serves 10,000s of customers who all have my addresses in their VPN boxes and ACLs on their firewalls. Myth: The need to multihome is proportional to the size of the organization. Fact: Some large organizations have only a few critical needs for the network and those needs are easily colocated in other facilities. For the rest of their use, being single-homed or multi-piped to a single provider is quite adequate. Some small organizations, OTOH, cannot function if their access to the network is impaired. For these organizations, multihoming is not only important, it's life and death. Myth: PI space is not needed in IPv6 because we fixed the need. Fact: PI space in IPv6 scares people because of the potential for unconstrained routing table growth. What is needed is to fundamentally change the way we do routing. IPv6 stopped well short of this goal, and, as such, provides little benefit beyond the original TUBA proposal, having decided that all of the real problems that needed to be solved were "too hard". IPv6 does nothing to eliminate the need for PI space and ASNs at end sites that need to be truly multihomed. Shim6 is an attempt at providing some level of workaround to this deficiency, but, for full functionality, it requires significant implementation on all affected end-nodes and some of the routing infrastructure. For now, it's just a pipe dream. In the long-run, it's a very complex hack to replace what could be a relatively simple correction. Owen -- If it wasn't crypto-signed, it probably didn't come from me. Attachment:
pgp00038.pgp
|