Mailing List Archive: NANOG: users

BGPttH. Neustar can do it, why can't we?

1 2

View All

Index | Next | Previous | View Threaded

j at arpa

Aug 5, 2012, 11:49 PM

Post #1 of 28 (690 views)
Permalink

BGPttH. Neustar can do it, why can't we?

discuss.

bill at herrin

Aug 6, 2012, 6:07 AM

Post #2 of 28 (664 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Mon, Aug 6, 2012 at 2:49 AM, jamie rishaw <j [at] arpa> 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 [at] dirtside bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

morrowc.lists at gmail

Aug 6, 2012, 7:08 AM

Post #3 of 28 (662 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill [at] herrin> 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

bicknell at ufp

Aug 6, 2012, 7:21 AM

Post #4 of 28 (665 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 [at] ufp - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

mansaxel at besserwisser

Aug 6, 2012, 7:23 AM

Post #5 of 28 (661 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 [at] gmail):
> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill [at] herrin> 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!!

Attachments:

signature.asc (0.19 KB)

bill at herrin

Aug 6, 2012, 7:27 AM

Post #6 of 28 (662 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow
<morrowc.lists [at] gmail> wrote:
> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill [at] herrin> 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 [at] dirtside bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

bill at herrin

Aug 6, 2012, 7:31 AM

Post #7 of 28 (664 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Mon, Aug 6, 2012 at 10:21 AM, Leo Bicknell <bicknell [at] ufp> 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 [at] dirtside bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

joelja at bogus

Aug 6, 2012, 7:36 AM

Post #8 of 28 (662 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On 8/6/12 7:08 AM, Christopher Morrow wrote:
> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill [at] herrin> 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
>

morrowc.lists at gmail

Aug 6, 2012, 7:45 AM

Post #9 of 28 (665 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Mon, Aug 6, 2012 at 10:27 AM, William Herrin <bill [at] herrin> wrote:
> On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow
> <morrowc.lists [at] gmail> wrote:
>> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill [at] herrin> 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 :(

morrowc.lists at gmail

Aug 6, 2012, 7:59 AM

Post #10 of 28 (663 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Mon, Aug 6, 2012 at 10:45 AM, Christopher Morrow
<morrowc.lists [at] gmail> wrote:
> On Mon, Aug 6, 2012 at 10:27 AM, William Herrin <bill [at] herrin> wrote:
>> On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow
>> <morrowc.lists [at] gmail> wrote:
>>> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill [at] herrin> 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

cboyd at gizmopartners

Aug 6, 2012, 8:05 AM

Post #11 of 28 (661 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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

bicknell at ufp

Aug 6, 2012, 8:11 AM

Post #12 of 28 (664 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 [at] ufp - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

swmike at swm

Aug 6, 2012, 8:19 AM

Post #13 of 28 (675 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 [at] swm

mike at mikejones

Aug 6, 2012, 9:51 AM

Post #14 of 28 (650 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On 6 August 2012 16:11, Leo Bicknell <bicknell [at] ufp> 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

bicknell at ufp

Aug 6, 2012, 10:26 AM

Post #15 of 28 (651 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 [at] ufp - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

owen at delong

Aug 6, 2012, 1:02 PM

Post #16 of 28 (641 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Aug 6, 2012, at 07:21 , Leo Bicknell <bicknell [at] ufp> 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

owen at delong

Aug 6, 2012, 1:03 PM

Post #17 of 28 (646 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Aug 6, 2012, at 07:27 , William Herrin <bill [at] herrin> wrote:

> On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow
> <morrowc.lists [at] gmail> wrote:
>> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin <bill [at] herrin> 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

khelms at ispalliance

Aug 6, 2012, 1:16 PM

Post #18 of 28 (641 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 at delong

Aug 6, 2012, 1:27 PM

Post #19 of 28 (641 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 [at] ispalliance> 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
> --------------------------------
>

khelms at ispalliance

Aug 6, 2012, 3:05 PM

Post #20 of 28 (633 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 [at] ispalliance> 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
--------------------------------

owen at delong

Aug 6, 2012, 3:55 PM

Post #21 of 28 (632 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

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 [at] ispalliance> 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 [at] ispalliance> 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
> --------------------------------

bill at herrin

Aug 6, 2012, 4:15 PM

Post #22 of 28 (639 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong <owen [at] delong> 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 [at] dirtside bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

sethm at rollernet

Aug 6, 2012, 4:36 PM

Post #23 of 28 (629 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On 8/6/12 4:15 PM, William Herrin wrote:
> On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong <owen [at] delong> 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

owen at delong

Aug 6, 2012, 4:38 PM

Post #24 of 28 (631 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Aug 6, 2012, at 16:15 , William Herrin <bill [at] herrin> wrote:

> On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong <owen [at] delong> 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

hvgeekwtrvl at gmail

Aug 6, 2012, 4:42 PM

Post #25 of 28 (627 views)
Permalink

Re: BGPttH. Neustar can do it, why can't we? [In reply to]

On Mon, Aug 6, 2012 at 3:55 PM, Owen DeLong <owen [at] delong> 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)

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".

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.

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 [at] ispalliance> 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 [at] ispalliance> 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

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads