Re: Networks ignoring prepends?

[James Jun <james.jun () towardex com>]

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