William Herrin wrote: > Nevertheless, in the protocol's design, the one expressed in the RFC's, AS > path length = distance.
Since we're opening RFCs now, and somehow it is being opined that LOCAL_PREF is a profit-driven conspiracy and a coordinated scheme concocted by commercial networks to tamper with, or "override" AS_PATH desires of the majority, let us review factually about what LOCAL_PREF actually does and why it was implemented into BGP in the first place: RFC 4277 entitled "Experience with the BGP-4 Protocol", Section 20: The NSFNET program used EGP, and then BGP, to provide external routing information. It was the NSF policy of offering different prices and providing different levels of support to the Research and Education (RE) and the Commercial (CO) networks that led to BGP's initial policy requirements. In addition to being charged more, CO networks were not able to use the NSFNET backbone to reach other CO networks. The rationale for higher prices was that commercial users of the NSFNET within the business and research entities should subsidize the RE community. Recognition that the Internet was evolving away from a hierarchical network to a mesh of peers led to changes away from EGP and BGP-1 that eliminated any assumptions of hierarchy. Enforcement of NSF policy was accomplished through maintenance of the NSF Policy Routing Database (PRDB). The PRDB not only contained each networks designation as CO or RE, but also contained a list of the preferred exit points to the NSFNET to reach each network. This was the basis for setting what would later be called BGP LOCAL_PREF on the NSFNET. Tools provided with the PRDB generated complete router configurations for the NSFNET. RFC 4271 entitled "A Border Gateway Protocol 4 (BGP-4)" (supersedes RFC 1771), Section 5.1.5: A BGP speaker SHALL calculate the degree of preference for each external route based on the locally-configured policy, and include the degree of preference when advertising a route to its internal peers. The higher degree of preference MUST be preferred. A BGP speaker uses the degree of preference learned via LOCAL_PREF in its Decision Process (see Section 9.1.1). It is clear by the experiences of NSFnet and early days of the Internet, that AS_PATH alone is insufficient to meet interconnection policy objectives. In fact, this LOCAL_PREF "conspiracy" was actually concocted by Research and Education (R&E) networks to make evil commercial networks pay--but in reality, NSFnet and early R&E networks had actual operational and demonstrated reasons for this, and a path vector routing protocol where cross-border interconnection policies must be applied cannot simply rely on AS_PATH for decision mechanism. Otherwise, it'd have been easier to just scale up RIP into a global routing protocol instead of using BGP. This is where your argument and basis of your claim fails-- a parameter to express administrative policy preference was required even in early days of NSFnet, and that is why LOCAL_PREF was put in there in the first place, despite your assertions claiming it is broken and being used to "override" AS_PATH to small guys for bad faith reasons. This was not some later "add-on" for conspiracy by commercial networks; LOCAL_PREF in fact, was one of the principal features and reasons for developing BGP-4. You're 29 years late to this conversation buddy. > > 4. Get yourself connected to 3356 directly. > > I am, just not as a BGP customer. And I won't be as a BGP customer. > Opening a ticket with them has not yielded results. Or any response > from network engineering at all. Just the frontline support who wants > me to reboot my modem. :( I get that you are not in the position to buy from 3356, and to that extent, that is a completely respectable and reasonable position (commercial reasons, personal experience/preference or otherwise, you are the customer here). But you have a voice as a customer on which BGP transit provider you're purchasing on the other end (the far-end location or data center where your ASN is operating and taking transit from) -- take it as a lesson learned going forward: when choosing a smaller/nimble or blended bandwidth IP provider, make sure you to ask, what can the provider do to help you achieve better connectivity into 3356 or any other network you're trying to get to? It's your transit provider's business to make sure your ASN's connectivity works to your expectations. Otherwise why would you, the customer, choose to do business with a middle-man when you could just buy direct from 3356 at the data center for your ASN instead? It is incumbent upon your IP transit provider to help you better meet your connectivity requirements (especially for retail and small traffic customers in data centers like yourself who are not subject to capacity or comercial interconnection disputes), and going forward, this is one area of requirements to be checked for during the RFQ process for procuring enterprise BGP-based IP transit. > > > 5. Keep yelling at the clouds about 3356 , even though they are doing the > > same thing that (to the best of my knowledge) every large transit provider > > does. > > 6. Pollute the DFZ because in light of what "every large transit > provider does," that's the solution that actually works. We've done our part to factually inform you on why BGP works the way it is using LOCAL_PREF, and why it is a very bad idea and actually operationally harmful to assume that AS_PATH should be the only metric that matters. Assuming that AS_PATH is the only metric that would matter demonstrates complete misunderstanding and misrepresentation of facts regarding the history of BGP and what the protocol is supposed to do. Your answer to these facts is to claim that we're defending 3356, perhaps there is some kind of a coordinated scheme by old school boyz club or something, and that you'll simply pollute everyone's routing table (either to spite or because that is the only option that works for you) because BGP is broken or is being "tampered with" for profit-driven reasons by your opinions held in view. You're welcome to do what you feel you'd need to do to meet your traffic-engineering requirements and hold whatever opinions you so desire, but you're not entitled to your own set of facts. I'm sure this will be an amusing case example for FIB compression algorithms to automatically filter out your said 'polluting' route, but that's a different conversation entirely. ;-) Regards, James
