BGPttH. Neustar can do it, why can't we?
On Mon, Aug 6, 2012 at 2:49 AM, jamie rishaw <j@arpa.com> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill@herrin.us> wrote:
As much as I'd love for Verizon to offer BGP directly over FIOS there are fewer than 40,000
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
Subject: Re: BGPttH. Neustar can do it, why can't we? Date: Mon, Aug 06, 2012 at 10:08:45AM -0400 Quoting Christopher Morrow (morrowc.lists@gmail.com):
On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill@herrin.us> wrote:
As much as I'd love for Verizon to offer BGP directly over FIOS there are fewer than 40,000
I'm curious as to your number... where is that from?
AS numbers used to be 16-bit. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I don't believe there really IS a GAS SHORTAGE.. I think it's all just a BIG HOAX on the part of the plastic sign salesmen -- to sell more numbers!!
On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill@herrin.us> wrote:
As much as I'd love for Verizon to offer BGP directly over FIOS there are fewer than 40,000
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?
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Mon, Aug 6, 2012 at 10:27 AM, William Herrin <bill@herrin.us> wrote:
On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill@herrin.us> wrote:
As much as I'd love for Verizon to offer BGP directly over FIOS there are fewer than 40,000
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?
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.
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 :(
On Mon, Aug 6, 2012 at 10:45 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Aug 6, 2012 at 10:27 AM, William Herrin <bill@herrin.us> wrote:
On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill@herrin.us> wrote:
As much as I'd love for Verizon to offer BGP directly over FIOS there are fewer than 40,000
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?
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.
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
On Aug 6, 2012, at 07:27 , William Herrin <bill@herrin.us> wrote:
On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill@herrin.us> wrote:
As much as I'd love for Verizon to offer BGP directly over FIOS there are fewer than 40,000
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?
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.
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 http://www.fatpipeinc.com/warp/index.html
This ignores the probability that cost effective BGP service availability would strongly drive demand for AS Numbers and adoption of the technology.
Owen
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
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 On Aug 6, 2012, at 13:16 , Scott Helms <khelms@ispalliance.net> wrote:
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
http://www.fatpipeinc.com/warp/index.html
This ignores the probability that cost effective BGP service availability would strongly drive demand for AS Numbers and adoption of the technology.
Owen
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
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. On 8/6/2012 4:27 PM, Owen DeLong wrote:
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
On Aug 6, 2012, at 13:16 , Scott Helms <khelms@ispalliance.net> wrote:
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
http://www.fatpipeinc.com/warp/index.html
This ignores the probability that cost effective BGP service availability would strongly drive demand for AS Numbers and adoption of the technology.
Owen
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
That's simply not true at all... Let's look at what it takes to configure BGP as I suggested... 1. The ASN number of the two providers 2. The ASN to be used for the local side 3. The IP Address to use on the local end of each connection 4. The IP Address to peer with on each connection 5. The prefix(es) to be advertised. Of these 5, only items 2 and 5 have to come from the customer and the customer needs to provide both of these to both ISPs anyway for them to configure their side. It would be trivial for providers and CPE vendors to develop a standardized API by which a router could retrieve all 5 pieces of information for a given connection once that connection is plugged in to the router. It could literally be as simple as: 1. Port gets address via SLAAC or DHCP 2. Port retrieves XML configuration document from http://bgpconfig.local (or user-specified URL provided by ISP, or whatever) <XML> <PROVIDERASN>6939</PROVIDERASN> <LOCALASN>65512</LOCALASN> <PROVIDERIPv4>192.0.2.21/30</PROVIDERIPv4> <PROVIDERIPv6>2001:db8:1fea:93a9::1/64</PROVIDERIPv6> <LOCALIPv4>192.0.2.22/30</LOCALIPv4> <LOCALIPv6>2001:db8:1fea:93a9::2/64</LOCALIPv6> <PrefixInformation> <PrefixAccepted>203.0.113.0/24</PrefixAccepted> <PrefixAccepted>198.51.100.0/24</PrefixAccepted> <PrefixAnnounced>0.0.0.0/0</PrefixAnnounced> </PrefixInformation> </XML> (Yes, I realize that is a bit of an oversimplification of the XML syntax, but you get the idea) 3. Router configures port and BGP session according to received XML document, including appropriate prefix filters. 4. Router runs with that XML based configuration as long as link-state and power remain. That would allow a zeroconf BGP-enabled router in relatively small hardware accepting a default route that would work at least as well as today's dual-NAT based boxes. Note that BGP is not redesigned or even altered to achieve this. Since Linksys/DLink/Netgear/$EVERYONE already has web servers and clients embedded in their gear, the XML parser (or JSON or whatever they choose to use for standard encoding) would be pretty straight forward. Yes, the operator/provider has to do some additional configuration, but speaking as a network operator, I know that this can be automated because the management of BGP configurations, including the filters _IS_ that automated where I work. If the provider is telling the router which prefixes to permit announcement of through the configuration URL, then it's even more reliable, right? Owen On Aug 6, 2012, at 15:05 , Scott Helms <khelms@ispalliance.net> wrote:
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.
On 8/6/2012 4:27 PM, Owen DeLong wrote:
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
On Aug 6, 2012, at 13:16 , Scott Helms <khelms@ispalliance.net> wrote:
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
http://www.fatpipeinc.com/warp/index.html
This ignores the probability that cost effective BGP service availability would strongly drive demand for AS Numbers and adoption of the technology.
Owen
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong <owen@delong.com> wrote:
That's simply not true at all...
Let's look at what it takes to configure BGP as I suggested...
1. The ASN number of the two providers 2. The ASN to be used for the local side 3. The IP Address to use on the local end of each connection 4. The IP Address to peer with on each connection 5. The prefix(es) to be advertised.
Add to that: 6. Primary A, Primary B, Balanced (routing priority via AS path prepends) 7. Optional password for each session (some ISPs require one) Or take another tack: have the SOHO router accept a URL for each BGP connection and have the provider build the config. Then all you enter is your provider-assigned interface address, a DNS server address and a URL. Your point is well taken. A leaf node BGP configuration could be simplified to the point where it fits on a SOHO router config page and does not require an expert to configure. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 8/6/12 4:15 PM, William Herrin wrote:
On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong <owen@delong.com> wrote:
That's simply not true at all...
Let's look at what it takes to configure BGP as I suggested...
1. The ASN number of the two providers 2. The ASN to be used for the local side 3. The IP Address to use on the local end of each connection 4. The IP Address to peer with on each connection 5. The prefix(es) to be advertised.
Add to that:
6. Primary A, Primary B, Balanced (routing priority via AS path prepends) 7. Optional password for each session (some ISPs require one)
Or take another tack: have the SOHO router accept a URL for each BGP connection and have the provider build the config. Then all you enter is your provider-assigned interface address, a DNS server address and a URL.
Your point is well taken. A leaf node BGP configuration could be simplified to the point where it fits on a SOHO router config page and does not require an expert to configure.
This is all being approached from the wrong angle; there's too much technical talk. "BGP to the Home" needs to be sales/marketing driven. (You're allowed to use buzzwords with no actual meaning though.) ~Seth
On Aug 6, 2012, at 16:15 , William Herrin <bill@herrin.us> wrote:
On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong <owen@delong.com> wrote:
That's simply not true at all...
Let's look at what it takes to configure BGP as I suggested...
1. The ASN number of the two providers 2. The ASN to be used for the local side 3. The IP Address to use on the local end of each connection 4. The IP Address to peer with on each connection 5. The prefix(es) to be advertised.
Add to that:
6. Primary A, Primary B, Balanced (routing priority via AS path prepends)
Not absolutely required and certainly going beyond what is required to provide slightly better than the functionality provided with the dual-NAT scenario.
7. Optional password for each session (some ISPs require one)
Fair enough, but pretty trivial.
Or take another tack: have the SOHO router accept a URL for each BGP connection and have the provider build the config. Then all you enter is your provider-assigned interface address, a DNS server address and a URL.
Well, I was going for zeroconf, but yes, that was basically allowed for in what I described.
Your point is well taken. A leaf node BGP configuration could be simplified to the point where it fits on a SOHO router config page and does not require an expert to configure.
Yep... And it could even be made 100% automated zeroconf with a little more effort. It could even use provider-assigned private-ASNs and a shared PA prefix with a little additional ingenuity. Owen
The problem you're missing is that there is 0 market pressure to build and standardize all of this. Netconf isn't a claimed standard yet much less a functional one in the SOHO world. Lets assume for a moment that someone finds enough of a reason to herd the cats that are the soho router market and gets them to adopt Netconf or another rational method for distributed configuration, you haven't dealt with the hardest problem. The router configuration isn't the most challenging one. _What_ to communicate or configure is the hard part and unless you're going to put the service provider in charge of the BGP session very few businesses have the internal OR external resources to answer these simple questions. 1. The ASN number of the two providers //smb response, what's an ASN? Why do I have pay for one, I already pay for Internet service. 2. The ASN to be used for the local side //read response 1 3. The IP Address to use on the local end of each connection //who figures this out? 4. The IP Address to peer with on each connection //same question 5. The prefix(es) to be advertised. //again, who figures this out? On 8/6/2012 7:38 PM, Owen DeLong wrote:
On Aug 6, 2012, at 16:15 , William Herrin <bill@herrin.us> wrote:
On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong <owen@delong.com> wrote:
That's simply not true at all...
Let's look at what it takes to configure BGP as I suggested...
1. The ASN number of the two providers 2. The ASN to be used for the local side 3. The IP Address to use on the local end of each connection 4. The IP Address to peer with on each connection 5. The prefix(es) to be advertised. Add to that:
6. Primary A, Primary B, Balanced (routing priority via AS path prepends) Not absolutely required and certainly going beyond what is required to provide slightly better than the functionality provided with the dual-NAT scenario.
7. Optional password for each session (some ISPs require one) Fair enough, but pretty trivial.
Or take another tack: have the SOHO router accept a URL for each BGP connection and have the provider build the config. Then all you enter is your provider-assigned interface address, a DNS server address and a URL. Well, I was going for zeroconf, but yes, that was basically allowed for in what I described.
Your point is well taken. A leaf node BGP configuration could be simplified to the point where it fits on a SOHO router config page and does not require an expert to configure.
Yep... And it could even be made 100% automated zeroconf with a little more effort.
It could even use provider-assigned private-ASNs and a shared PA prefix with a little additional ingenuity.
Owen
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
On Mon, Aug 6, 2012 at 3:55 PM, Owen DeLong <owen@delong.com> wrote:
That's simply not true at all...
Let's look at what it takes to configure BGP as I suggested...
1. The ASN number of the two providers 2. The ASN to be used for the local side 3. The IP Address to use on the local end of each connection 4. The IP Address to peer with on each connection 5. Te prefix(es) to be advertised.
Of these 5, only items 2 and 5 have to come from the customer and the customer needs to provide both of these to both ISPs anyway for them to configure their side.
It would be trivial for providers and CPE vendors to develop a standardized API by which a router could retrieve all 5 pieces of information for a given connection once that connection is plugged in to the router. It could literally be as simple as:
1. Port gets address via SLAAC or DHCP 2. Port retrieves XML configuration document from http://bgpconfig.local (or user-specified URL provided by ISP, or whatever) <XML> <PROVIDERASN>6939</PROVIDERASN> <LOCALASN>65512</LOCALASN> <PROVIDERIPv4>192.0.2.21/30</PROVIDERIPv4> <PROVIDERIPv6>2001:db8:1fea:93a9::1/64</PROVIDERIPv6> <LOCALIPv4>192.0.2.22/30</LOCALIPv4> <LOCALIPv6>2001:db8:1fea:93a9::2/64</LOCALIPv6> <PrefixInformation> <PrefixAccepted>203.0.113.0/24</PrefixAccepted> <PrefixAccepted>198.51.100.0/24</PrefixAccepted> <PrefixAnnounced>0.0.0.0/0</PrefixAnnounced> </PrefixInformation> </XML>
(Yes, I realize that is a bit of an oversimplification of the XML syntax, but you get the idea)
3. Router configures port and BGP session according to received XML document, including appropriate prefix filters.
4. Router runs with that XML based configuration as long as link-state and power remain.
That would allow a zeroconf BGP-enabled router in relatively small hardware accepting a default route that would work at least as well as today's dual-NAT based boxes. Note that BGP is not redesigned or even altered to achieve this. Since Linksys/DLink/Netgear/$EVERYONE already has web servers and clients embedded in their gear, the XML parser (or JSON or whatever they choose to use for standard encoding) would be pretty straight forward.
From a SMB perspective this is part of the problem. Why pay for:
From an SMB who has a staff on hand it still may not be worth it if
1. An ASN 2. 2 BGP connections 3. PI space 4. More expensive hardware (potentially and probably) when I'm only going to get a Default Route? I've added complexity to my life, administrative and OPEX overhead when I'm getting no benefits of BGP other than a default route. I can get a default route from a provider without adding complexity and overhead. An SMB who does not have a staff on hand wants it cheap and to work. Everything else is a potential expense they don't want to spend. They don't want to have to call either their support company or vendor because the "Internet is down", at most they want to pull the power on the router and plug it back in and have it all work. At best they want to only know what that "little black box with the blinky lights" is when someone packs it into a box because it's wasting power and now the "Internet is broken". they don't have someone who is BGP smart. And truth to tell *you* don't want more BGP idiots polluting the routing table either intentionally or unintentionally. Conversely if you do make BGP that available to SMB's and home users (not necessarily a bad thing) the issues with routing table size has to be dealt with. Right now there are roughly 42K ASes with routes in the routing table. Add SMB's and home users and your looking at potentially millions of ASes with routes in the routing table. Heck if you *only* double the ASes and associated routes many many routers are going to crash and need replacement.
Yes, the operator/provider has to do some additional configuration, but speaking as a network operator, I know that this can be automated because the management of BGP configurations, including the filters _IS_ that automated where I work. If the provider is telling the router which prefixes to permit announcement of through the configuration URL, then it's even more reliable, right?
Owen
On Aug 6, 2012, at 15:05 , Scott Helms <khelms@ispalliance.net> wrote:
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.
On 8/6/2012 4:27 PM, Owen DeLong wrote:
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
On Aug 6, 2012, at 13:16 , Scott Helms <khelms@ispalliance.net> wrote:
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
http://www.fatpipeinc.com/warp/index.html
This ignores the probability that cost effective BGP service availability would strongly drive demand for AS Numbers and adoption of the technology.
Owen
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
james
On Aug 6, 2012, at 16:42 , james machado <hvgeekwtrvl@gmail.com> wrote:
On Mon, Aug 6, 2012 at 3:55 PM, Owen DeLong <owen@delong.com> wrote:
That's simply not true at all...
Let's look at what it takes to configure BGP as I suggested...
1. The ASN number of the two providers 2. The ASN to be used for the local side 3. The IP Address to use on the local end of each connection 4. The IP Address to peer with on each connection 5. Te prefix(es) to be advertised.
Of these 5, only items 2 and 5 have to come from the customer and the customer needs to provide both of these to both ISPs anyway for them to configure their side.
It would be trivial for providers and CPE vendors to develop a standardized API by which a router could retrieve all 5 pieces of information for a given connection once that connection is plugged in to the router. It could literally be as simple as:
1. Port gets address via SLAAC or DHCP 2. Port retrieves XML configuration document from http://bgpconfig.local (or user-specified URL provided by ISP, or whatever) <XML> <PROVIDERASN>6939</PROVIDERASN> <LOCALASN>65512</LOCALASN> <PROVIDERIPv4>192.0.2.21/30</PROVIDERIPv4> <PROVIDERIPv6>2001:db8:1fea:93a9::1/64</PROVIDERIPv6> <LOCALIPv4>192.0.2.22/30</LOCALIPv4> <LOCALIPv6>2001:db8:1fea:93a9::2/64</LOCALIPv6> <PrefixInformation> <PrefixAccepted>203.0.113.0/24</PrefixAccepted> <PrefixAccepted>198.51.100.0/24</PrefixAccepted> <PrefixAnnounced>0.0.0.0/0</PrefixAnnounced> </PrefixInformation> </XML>
(Yes, I realize that is a bit of an oversimplification of the XML syntax, but you get the idea)
3. Router configures port and BGP session according to received XML document, including appropriate prefix filters.
4. Router runs with that XML based configuration as long as link-state and power remain.
That would allow a zeroconf BGP-enabled router in relatively small hardware accepting a default route that would work at least as well as today's dual-NAT based boxes. Note that BGP is not redesigned or even altered to achieve this. Since Linksys/DLink/Netgear/$EVERYONE already has web servers and clients embedded in their gear, the XML parser (or JSON or whatever they choose to use for standard encoding) would be pretty straight forward.
From a SMB perspective this is part of the problem. Why pay for:
1. An ASN 2. 2 BGP connections 3. PI space 4. More expensive hardware (potentially and probably)
1-3 are optional and not required for what I proposed. You could do it with a private ASN, PA space and an LOA if you don't care about provider mobility. I would argue that 4 assumes facts not in evidence.
when I'm only going to get a Default Route? I've added complexity to my life, administrative and OPEX overhead when I'm getting no benefits of BGP other than a default route. I can get a default route from a provider without adding complexity and overhead.
The goal here was to make this as simple and cost-effective as the NAT-based IPv4 solution currently in common use. There's no reason it can't be exactly that. It does provide advantages over the NAT-based solution (sessions can survive failover). You certainly have the option of a more complex BGP configuration, but that does require a more expensive router and probably 1-3 as well.
An SMB who does not have a staff on hand wants it cheap and to work.
Which is why I proposed a mechanism by which it could be zero-configuration, zero additional cost, and provide only marginal benefits over the current IPv4 configuration while also supporting IPv6.
Everything else is a potential expense they don't want to spend. They don't want to have to call either their support company or vendor because the "Internet is down", at most they want to pull the power on the router and plug it back in and have it all work. At best they want to only know what that "little black box with the blinky lights" is when someone packs it into a box because it's wasting power and now the "Internet is broken".
Right... I believe what I proposed comes as close to that as current SOHO routers that are in common use in the SMB world.
From an SMB who has a staff on hand it still may not be worth it if they don't have someone who is BGP smart. And truth to tell *you* don't want more BGP idiots polluting the routing table either intentionally or unintentionally.
No BGP expertise required... Look again at what I proposed... All configuration of the BGP is done automatically and dictated by the ISP.
Conversely if you do make BGP that available to SMB's and home users (not necessarily a bad thing) the issues with routing table size has to be dealt with. Right now there are roughly 42K ASes with routes in the routing table. Add SMB's and home users and your looking at potentially millions of ASes with routes in the routing table. Heck if you *only* double the ASes and associated routes many many routers are going to crash and need replacement.
First, that's not an unsolvable problem and it's a crying shame that the IETF punted on it instead of solving it as part of the IPv6 design. Second, I think most of these would be stub-AS using private ASNs mapped into their upstream providers AS. Yes, it will add prefixes, but anyone who multihomes today is going to end up being a prefix in IPv6. Overall, I'd say that's a problem we have to solve one way or another. Owen
Yes, the operator/provider has to do some additional configuration, but speaking as a network operator, I know that this can be automated because the management of BGP configurations, including the filters _IS_ that automated where I work. If the provider is telling the router which prefixes to permit announcement of through the configuration URL, then it's even more reliable, right?
Owen
On Aug 6, 2012, at 15:05 , Scott Helms <khelms@ispalliance.net> wrote:
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.
On 8/6/2012 4:27 PM, Owen DeLong wrote:
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
On Aug 6, 2012, at 13:16 , Scott Helms <khelms@ispalliance.net> wrote:
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
http://www.fatpipeinc.com/warp/index.html
This ignores the probability that cost effective BGP service availability would strongly drive demand for AS Numbers and adoption of the technology.
Owen
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
james
On 8/6/12 8:04 PM, Owen DeLong wrote:
The goal here was to make this as simple and cost-effective as the NAT-based IPv4 solution currently in common use. There's no reason it can't be exactly that.
It does provide advantages over the NAT-based solution (sessions can survive failover).
What do people think about Fred Templin's IRON multihomed tunneling approach (or LISP, I guess it can do it)? IRON should give you multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming traffic. It's less reliable than BGP in theory since you'd be virtually single-homed to your IRON provider but that might be a worthwhile tradeoff since staying up is pretty much their purpose in life. You'd have to pay a third provider to terminate your tunnels, but that might be cheaper than paying an extra BGP tax to both of your physical providers. IRON appears to require much less configuration than BGP and it can also provide IPv6 over v4-only providers (good luck finding *two* broadband providers in the same location that provide IPv6 and BGP). -- Wes Felter IBM Research - Austin
On Aug 7, 2012, at 10:50 , Wes Felter <wmf@felter.org> wrote:
On 8/6/12 8:04 PM, Owen DeLong wrote:
The goal here was to make this as simple and cost-effective as the NAT-based IPv4 solution currently in common use. There's no reason it can't be exactly that.
It does provide advantages over the NAT-based solution (sessions can survive failover).
What do people think about Fred Templin's IRON multihomed tunneling approach (or LISP, I guess it can do it)? IRON should give you multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming traffic. It's less reliable than BGP in theory since you'd be virtually single-homed to your IRON provider but that might be a worthwhile tradeoff since staying up is pretty much their purpose in life.
You'd have to pay a third provider to terminate your tunnels, but that might be cheaper than paying an extra BGP tax to both of your physical providers. IRON appears to require much less configuration than BGP and it can also provide IPv6 over v4-only providers (good luck finding *two* broadband providers in the same location that provide IPv6 and BGP).
-- Wes Felter IBM Research - Austin
I think IRON has some promise as well and might be interesting in some scenarios. I think developing both is worth while. Different tools for different jobs. Owen
I realize that this is reaching way back, but you may want to have a look at the latest version of IRON: http://www.ietf.org/id/draft-templin-ironbis-12.txt IRON manages the internal routing systems for large virtual service provider networks. It deals with deaggregation and churn due to mobility internally, and does not expose the deaggregation and churn to the interdomain routing system. IRON is therefore an intradomain routing overlay network system, and can be used in conjunction with any interdomain routing system - including BGP and LISP. Thanks - Fred fred.l.templin@boeing.com
-----Original Message----- From: Wes Felter [mailto:wmf@felter.org] Sent: Tuesday, August 07, 2012 10:51 AM To: nanog@nanog.org Subject: IRON vs. BGP (was Re: BGPttH. Neustar can do it, why can't we?)
On 8/6/12 8:04 PM, Owen DeLong wrote:
The goal here was to make this as simple and cost-effective as the NAT- based IPv4 solution currently in common use. There's no reason it can't be exactly that.
It does provide advantages over the NAT-based solution (sessions can survive failover).
What do people think about Fred Templin's IRON multihomed tunneling approach (or LISP, I guess it can do it)? IRON should give you multihoming with stable IPv4 and IPv6 PA prefixes, even for incoming traffic. It's less reliable than BGP in theory since you'd be virtually single-homed to your IRON provider but that might be a worthwhile tradeoff since staying up is pretty much their purpose in life.
You'd have to pay a third provider to terminate your tunnels, but that might be cheaper than paying an extra BGP tax to both of your physical providers. IRON appears to require much less configuration than BGP and it can also provide IPv6 over v4-only providers (good luck finding *two* broadband providers in the same location that provide IPv6 and BGP).
-- Wes Felter IBM Research - Austin
On Tue, Oct 23, 2012 at 4:13 PM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
I realize that this is reaching way back, but you may want to have a look at the latest version of IRON:
http://www.ietf.org/id/draft-templin-ironbis-12.txt
IRON manages the internal routing systems for large virtual service provider networks. It deals with deaggregation and churn due to mobility internally, and does not expose the deaggregation and churn to the interdomain routing system.
IRON is therefore an intradomain routing overlay network system, and can be used in conjunction with any interdomain routing system - including BGP and LISP.
someone should have brought this up in the ARMD working group...
On Mon, 06 Aug 2012 15:55:19 -0700, Owen DeLong said:
That would allow a zeroconf BGP-enabled router in relatively small hardware accepting a default route t
OK Owen, I'll bite - what are the chances that a zeroconf router will accept the *wrong* default route? If you're trying to do the "Use this provider unless it dies, then use the other link", you can't really do that as zero-conf, you'll need to tell it which side is A and which is B. And if you're trying to do routing across both links at once, that's even worse for zeroconf.
On 8/6/12 7:08 AM, Christopher Morrow wrote:
On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill@herrin.us> wrote:
As much as I'd love for Verizon to offer BGP directly over FIOS there are fewer than 40,000 I'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.
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
On Aug 6, 2012, at 9:08 AM, Christopher Morrow wrote:
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?
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? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Mon, 6 Aug 2012, Leo Bicknell wrote:
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 6 August 2012 16:11, Leo Bicknell <bicknell@ufp.org> wrote:
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. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
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? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Mon, Aug 6, 2012 at 10:21 AM, Leo Bicknell <bicknell@ufp.org> wrote:
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?
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Aug 6, 2012, at 07:21 , Leo Bicknell <bicknell@ufp.org> wrote:
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?
I'd pay it in a heartbeat. Owen
participants (16)
-
Chris Boyd -
Christopher Morrow -
james machado -
jamie rishaw -
joel jaeggli -
Leo Bicknell -
Mikael Abrahamsson -
Mike Jones -
Måns Nilsson -
Owen DeLong -
Scott Helms -
Seth Mattinen -
Templin, Fred L -
valdis.kletnieks＠vt.edu -
Wes Felter -
William Herrin