Networks ignoring prepends?

Wed Jan 24 18:05:03 UTC 2024

On Wed, Jan 24, 2024 at 09:22:06AM -0800, William Herrin wrote:
> On Wed, Jan 24, 2024 at 8:39???AM James Jun <james.jun at towardex.com> wrote:
> > On Wed, Jan 24, 2024 at 08:16:56AM -0800, William Herrin wrote:
> > > Sophistry. I buy IP transit from 3 providers, one of which has a 3 AS
> > > path to 3356.
> >
> > Again you omit context.
> 
> What you're calling context, I call deceptive.
> 
> For one thing, Centurylink's process is, like a spammer, opt-out
> rather than opt-in. 

Nope. Your allegation that Lumen (Centurylink)'s "process" is out-out like a spammer is factually and historically incorrect.  However, Lumen's practice is complaint with best common practices and experiences as documented on RFC 4277 and provided by RFC 4271.

Lumen/Centurylink's alleged "opt-out spamming" practice predates their very existence and was established during the NSFNET, with an operational need at the time to differenciate commercial networks from R&E networks. Just as R&E networks needed to treat commercial network traffic differently during the needs of the NSFNET, commercial operators of the Internet are also expected and demanded to prioritize traffic by their paying customers, over non-paying customers.

> 3356 enables the local pref unless told through a
> BGP community not to. There's no evidence that 47787 even knows that
> Centurylink is preferring them despite shorter AS paths elsewhere, let
> alone desires that behavior. Indeed, given the prepends that 47787
> added, it's quite possible they desire the opposite.

The evidence is widely documented and is in best common practices of every major ASN exercising routing policy and subsequent RFCs and BCPs published concerning discussions herein.  Internet standards and documented widely accepted current practices exist for a good reason.  Your, or alleged 47787's possibility of failure, ignorance or act of ommission in being informed of how the current practices work does not make you any less responsible in identifying the problem at hand.  Your allegation and arguments that currently adopted and documented inter-AS traffic engineering practices are deceptive and "opt-out" in a bad-faith nature are simply too tenuous a connection and amount to reductio ad absurdum.  You are however welcome to participate in IETF process to propose to alter the way BGP practices work for the better, as you wish.  That's what's so great about community input-based policy development processes.

> 
> For another, a key implication in your "context" is that if one
> customer intentionally pays 3356 to intentionally send another
> customer's packets on a longer, slower trip than 3356 otherwise would,
> that's a legitimate above-board business transaction. Not obviously
> corrupt.

False.  None of the parties described herein, neither 47784, nor 3356 are liable in "intentionally" sending traffic of another customer on a longer, less efficient path.  What they are however likely liable for, are contractual obligations and commercial expectations of bilateral parties engaged in an ongoing transaction.  You fit into the chain of buying from 53356 without understanding the underlying infrastructure and connectivity relationships that 53356 has toward 3356.  And you're now litigating that it's corrupt and is possibly some kind of a coordinated scheme or a racket without your consent.  You gave your consent by agreeing to run BGP with 53356 as your vendor, which you awarded that business to, and began advertising your prefix.  It's not working the way you want, so engage with your vendor to fix it, or fire them.  This is not hard.

James