Home page logo
/

nanog logo nanog mailing list archives

Re: BGPttH. Neustar can do it, why can't we?
From: Owen DeLong <owen () delong com>
Date: Mon, 6 Aug 2012 18:04:35 -0700


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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]