On Aug 6, 2012, at 16:42 , james machado <[email protected]> wrote:
> On Mon, Aug 6, 2012 at 3:55 PM, Owen DeLong <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
