discuss.
Commodity service from a commodity provider. As much as I'd love for
Verizon to offer BGP directly over FIOS there are fewer than 40,000
customers worldwide for such a service. As long as they maintain
sufficient network neutrality to get high speed tunnel service with
someone and run BGP over the tunnel their behavior is not outrageous.
To facilitate this and all the folks with custom needs, a wireline
provider should have a choice between unbundling and open
settlement-free peering. Mandatory to do at least one. But that's a
whole other can of worms.
Regards,
Bill Herrin
I'm curious as to your number... where is that from?
Marhsall had noted a number of 'small businesses' in the US at ~1.4m
as of ~2006ish?
I'd think that there are many use-cases where BGP is useful for end
users of FIOS, turning out a 'business' class of service without BGP
seems like a less useful 'business' solution (especially where the sla
isn't really much better than the consumer solution).
-chris
In a message written on Mon, Aug 06, 2012 at 01:49:07AM -0500, jamie rishaw wrote:
discuss.
It's a short sighted result created by the lack of competition.
IP access is a commodity service, with thin margins that will only
get thinner. Right now those margins are being propped up in many
locations by monopoly or near-monopoly status, which creates a
situation where companies neither need to compete on features and
service quality nor do they need to turn to those areas to maintain
a profit.
If there was meaningful competition, the margin on raw IP access
would decline and companies would have to turn to value-add services
to maintain a profit margin. From the simple up-sell of a static
IP address that some do today, to a fee for BGP, a fee for DDOS
mitigation, and so on. These are all things it's not uncommon to
see when buying service in carrier netural colos where there is
competition.
There is no technological problem here. BGP to the end user has a
cost. The current business climate is causing people to cut all
possible costs and offering no incentive to innvovate and up-charge.
Which leads to an interesting question. If on top of your $100/month
"business class Internet" the provider were to charge $50/month for
"BGP Access" to cover their costs of having a human configure the
session, larger access gear to handle the routes, and larger backbone
gear to deal with a larger routing table, would you still be as
gung ho about BGP to the business?
> As much as I'd love for
> Verizon to offer BGP directly over FIOS there are fewer than 40,000I'm curious as to your number... where is that from?
AS numbers used to be 16-bit.
Hi Chris,
Lacking any reason to believe otherwise, I estimate the number of BGP
users at reasonably close to the number of autonomous systems in the
Internet BGP table. Technically that doesn't have to be true... but
given the debugging nuissance associated with private AS numbers and
the trivial ease and cost with which an AS is registered it seems
likely to me.
Regards,
Bill Herrin
Speaking for myself, yes, I'd pay the extra $50 and be glad. If it was
$500... well, I don't have that level of need for my basement. But I
have two clients who would gladly add $500 on top of a business fios
to get BGP.
Regards,
Bill Herrin
As much as I'd love for
Verizon to offer BGP directly over FIOS there are fewer than 40,000I'm curious as to your number... where is that from?
sent to your mailbox every week
AS Summary
41838 Number of ASes in routing system
http://www.cidr-report.org/as2.0/#General_Status
the majority of those are stub ASes and more than 1/3 of them are announcing only one prefix.
The addressable market of potential multihomers is probably larger than that. but frankly there's a lot of friction that makes the proposition less than worthwhile for most businesses.
e.g. p.i. versus pa prefix assignment.
longish commitments to two or more providers
facilties
expertise
...
In ipv4 land, a nat box with two uplinks is probably a 90% solution for most non-services-offering high(er) availability needing small businesses.
I know that 701 had many 'private' (AS7046) customer peerings than
public... it doesn't seem out of the realm of possibility that other
networks have the same situation. I think Marshall's numbers were
based on some small-business-SEC thing, it'd be nice if he piped up
with where he got the number though 
I did some searching with webcrawler and found:
<https://www.arin.net/meetings/minutes/ARIN_XX/PDF/wednesday/RoutingTable_Schiller.pdf>
which on slide 2 credits marshall (from before the slide which is
dated 2005), the actual number is not (sadly) shown in the slides...
This message from Marshall alludes to sending the numbers to Vince
Fuller, Marshall goes on to say:
<http://www.mhonarc.org/archive/html/ietf/2007-09/msg00199.html>
"Yes, I gave numbers to Vince Fuller about millions of multi-homers,
but that was to set an upper bound on the process. I do no believe
that every small business will rush out and multi-home, no matter how
automated BGP becomes."
So clearly he's betting as Joel has (and William as well) that the
number will be below his 1.4m total businesses, but above the current
40k asns, I would think.
-chris
Speaking as someone who does a lot of work supporting small business IT, I suspect the number is much lower. As a group, these customers tend to be extremely cost averse. Paying for a secondary access circuit may become important as cloud applications become more critical for the market segment, but existing smart NAT boxes that detect primary upstream failure and switch over to a secondary ISP will work for many cases. Yes, it's ugly, but it gets them reconnected to the off-site email server and the payment card gateway.
--Chris
In a message written on Mon, Aug 06, 2012 at 10:05:30AM -0500, Chris Boyd wrote:
Speaking as someone who does a lot of work supporting small business IT, I suspect the number is much lower. As a group, these customers tend to be extremely cost averse. Paying for a secondary access circuit may become important as cloud applications become more critical for the market segment, but existing smart NAT boxes that detect primary upstream failure and switch over to a secondary ISP will work for many cases. Yes, it's ugly, but it gets them reconnected to the off-site email server and the payment card gateway.
I don't even think the dual-uplink NAT box is that ugly of a solution.
Sure it's outbound only, but for a lot of applications that's fine.
However, it causes me to ask a differnet question, how will this
work in IPv6? Does anyone make a dual-uplink IPv6 aware device?
Ideally it would use DHCP-PD to get prefixes from two upstream
providers and would make both available on the local LAN. Conceptually
it would then be easy to policy route traffic to the correct provider.
But of course the problem comes down to the host, it now needs to
know how to switch between source addresses in some meaningful way,
and the router needs to be able to signal it.
As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might
be a relatively clean solution. Are there other deployable, or nearly
deployable solutions?
However, it causes me to ask a differnet question, how will this work in IPv6? Does anyone make a dual-uplink IPv6 aware device? Ideally it would use DHCP-PD to get prefixes from two upstream providers and would make both available on the local LAN. Conceptually it would then be easy to policy route traffic to the correct provider. But of course the problem comes down to the host, it now needs to know how to switch between source addresses in some meaningful way, and the router needs to be able to signal it.
There are working groups in the IETF looking into how to make this work, "homenet", "v6ops" and a few others. After a while one runs into protocol extensions or behavioural changes and things become non-trivial.
As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might be a relatively clean solution. Are there other deployable, or nearly deployable solutions?
Yes, there are a lot of possible options. Feel free to participate in the process. There is nothing that is deployable right now though.
In a message written on Mon, Aug 06, 2012 at 10:05:30AM -0500, Chris Boyd wrote:
Speaking as someone who does a lot of work supporting small business IT, I suspect the number is much lower. As a group, these customers tend to be extremely cost averse. Paying for a secondary access circuit may become important as cloud applications become more critical for the market segment, but existing smart NAT boxes that detect primary upstream failure and switch over to a secondary ISP will work for many cases. Yes, it's ugly, but it gets them reconnected to the off-site email server and the payment card gateway.
I don't even think the dual-uplink NAT box is that ugly of a solution.
Sure it's outbound only, but for a lot of applications that's fine.However, it causes me to ask a differnet question, how will this
work in IPv6? Does anyone make a dual-uplink IPv6 aware device?
Ideally it would use DHCP-PD to get prefixes from two upstream
providers and would make both available on the local LAN. Conceptually
it would then be easy to policy route traffic to the correct provider.
But of course the problem comes down to the host, it now needs to
know how to switch between source addresses in some meaningful way,
and the router needs to be able to signal it.
Multiple prefixes is very simple to do without needing a dual uplink
router, just get 2 "normal" routers and have them both advertise their
own prefixes, the problem is the policy routing that you mentioned a
dual WAN router would do.
A client that sees prefix A from router A and prefix B from router B
should IMO prefer router A for traffic from prefix A and router B for
traffic from prefix B. Current implementations seem to abstract away
the addressing and the routing in to completely separate things
resulting in it picking a default router then using that for all
traffic, this isn't too much of a problem if neither of your upstreams
do any source address filtering but I would much rather OS vendors
change their implementations than tell ISPs to stop filtering their
customers.
As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might
be a relatively clean solution. Are there other deployable, or nearly
deployable solutions?
If you have a router that sends out RAs with lifetime 0 when the
prefix goes away then this should be deployable for "poor mans
failover" (the same category I put IPv4 NAT in), however there are
some bugs with client implementations and some clients might refuse to
use that prefix/router again until they have rebooted which could be
an issue for infrequently rebooted clients if the other connection
later goes down. A lifetime of 1 instead of 0 should in theory work
around this behaviour but I haven't seen any implementations that do
this and haven't tested myself.
It's a shame that this IPv6 stuff doesn't work properly out of the
box, I fear that there will be a lot of hackery due to early
limitations that will stick around - for example if NAT becomes
readily available before clients can properly handle multiple prefixes
from multiple routers (and DHCP-PD chaining, and the various other
"we're working on it" things), then even once clients start being able
to do it properly I suspect people will still stick to their beloved
NAT because that's what they are used to.
- Mike
In a message written on Mon, Aug 06, 2012 at 05:51:02PM +0100, Mike Jones wrote:
If you have a router that sends out RAs with lifetime 0 when the
prefix goes away then this should be deployable for "poor mans
failover" (the same category I put IPv4 NAT in), however there are
If your provider does Unicast RPF strict mode, which I hope _all_
end user and small business connections default to doing this won't
work. The traffic has to be policy routed out based on the source
IP.
Having the host stack do that is an acceptable solution (your dual
router model) I think, but I don't know of a single one that does
that today.
I'd pay it in a heartbeat.
Owen
This ignores the probability that cost effective BGP service availability would
strongly drive demand for AS Numbers and adoption of the technology.
Owen
Probability is much too strong IMO. Most businesses don't even consider multi-homing and many that do use NAT devices with several connections rather than trying to run BGP.
#not associated nor do I recommend, just an example
Respectfully, I disagree... I think this is a causal chain...
1. Lack of cost-effective BGP-based service means that
2. CPE vendors are not motivated to provide self-configuring bgp-speaking routers to behave in this manner means that
3. SMBs seek other solutions using available CPE technology.
If cost-effective BGP-based service were available, providers would likely work with CPE vendors to get automation features added to products to support such services and multihomed organizations would definitely want to use those features.
Owen
Owen,
That's like saying if it were easy to fly we'd all be pilots, which isn't true either. BGP would need to be completely redesigned/replaced before it could possibly be automated to that level much less implemented by the Lynksis/DLink/Netgear/$yourfavoritesohorouter vendor. Business would need a reason to implement BGP and most simply don't AND BGP would have to be dramatically simpler and safer. Operators already have to be deeply involved (AKA filtering the announced networks) with edge network BGP implementations to prevent someone from announcing they're the preferred route for some other organization's netblock. This happens already on occasion and all of the people who run routers speaking BGP are generally professionals.