[155377] 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 18:56:47 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <50203FA1.8050503@ispalliance.net>
Date: Mon, 6 Aug 2012 15:55:19 -0700
To: Scott Helms <khelms@ispalliance.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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,
>=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
>>> --=20
>>> Scott Helms
>>> Vice President of Technology
>>> ZCorum
>>> (678) 507-5000
>>> --------------------------------
>>> http://twitter.com/kscotthelms
>>> --------------------------------
>>>=20
>>=20
>=20
>=20
> --=20
> Scott Helms
> Vice President of Technology
> ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
