Re: Networks ignoring prepends?

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

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 () 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