[155387] in North American Network Operators' Group
Re: BGPttH. Neustar can do it, why can't we?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Aug 6 21:06:32 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CADVasu5ov8j06vC6htcXm+f_Hifyggr_ZMCjegfbSsbH7+F-uQ@mail.gmail.com>
Date: Mon, 6 Aug 2012 18:04:35 -0700
To: james machado <hvgeekwtrvl@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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...
>>=20
>> Let's look at what it takes to configure BGP as I suggested...
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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:
>>=20
>> 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>
>>=20
>> (Yes, I realize that is a bit of an oversimplification of the XML =
syntax, but you get the idea)
>>=20
>> 3. Router configures port and BGP session according to =
received XML document, including
>> appropriate prefix filters.
>>=20
>> 4. Router runs with that XML based configuration as long =
as link-state and power remain.
>>=20
>> 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.
>>=20
>=20
>> =46rom a SMB perspective this is part of the problem. Why pay for:
>=20
> 1. An ASN
> 2. 2 BGP connections
> 3. PI space
> 4. More expensive hardware (potentially and probably)
>=20
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.
>=20
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.
>=20
>> =46rom 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.
>=20
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
>=20
>=20
>> 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?
>>=20
>> Owen
>>=20
>> On Aug 6, 2012, at 15:05 , Scott Helms <khelms@ispalliance.net> =
wrote:
>>=20
>>> Owen,
>>>=20
>>> 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.
>>>=20
>>> On 8/6/2012 4:27 PM, Owen DeLong wrote:
>>>> Respectfully, I disagree... I think this is a causal chain...
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Owen
>>>>=20
>>>> On Aug 6, 2012, at 13:16 , Scott Helms <khelms@ispalliance.net> =
wrote:
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> #not associated nor do I recommend, just an example
>>>>>=20
>>>>> http://www.fatpipeinc.com/warp/index.html
>>>>>=20
>>>>>=20
>>>>>> This ignores the probability that cost effective BGP service =
availability would
>>>>>> strongly drive demand for AS Numbers and adoption of the =
technology.
>>>>>>=20
>>>>>> Owen
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> --
>>>>> Scott Helms
>>>>> Vice President of Technology
>>>>> ZCorum
>>>>> (678) 507-5000
>>>>> --------------------------------
>>>>> http://twitter.com/kscotthelms
>>>>> --------------------------------
>>>>>=20
>>>>=20
>>>=20
>>>=20
>>> --
>>> Scott Helms
>>> Vice President of Technology
>>> ZCorum
>>> (678) 507-5000
>>> --------------------------------
>>> http://twitter.com/kscotthelms
>>> --------------------------------
>>=20
>>=20
>=20
>=20
>=20
> james
