Destination Preference Attribute for BGP

Fri Aug 18 20:25:41 UTC 2023

Fact remains, operators scrub communities and path-attributes for many reasons.
That's why as-path length is used as a traffic engineering mechanism over multiple AS hops.
As limited as it is, it's what we have.

Kind Regards,
Jakob

From: Jakob Heitz (jheitz) <jheitz at cisco.com>
Date: Friday, August 18, 2023 at 1:20 PM
To: Robert Raszuk <robert at raszuk.net>
Cc: nanog at nanog.org <nanog at nanog.org>
Subject: Re: Destination Preference Attribute for BGP
We support platforms of various capacities.
While we would all like to sell the large ones, people buy the cheap ones too.

Kind Regards,
Jakob

From: Robert Raszuk <robert at raszuk.net>
Date: Friday, August 18, 2023 at 12:55 PM
To: Jakob Heitz (jheitz) <jheitz at cisco.com>
Cc: nanog at nanog.org <nanog at nanog.org>
Subject: Re: Destination Preference Attribute for BGP
Jakob,

Considering how much various junk is being added to BGP protocol these days communities are your least worry as far as RAM space and protocol convergence time would be of any concern. Then you have those new concepts of limited/trusted domains where blast radius of much higher caliber then what communities would ever reach extends across ASNs.

It is interesting that not many folks from this list are participating in IETF IDR WG and voice concerns in respect to new BGP extensions which in the vast majority has nothing to do with Interdomain IPv4 or IPv6 routing.

While it is great that you keep fixing bugs I would encourage your platform/RP designers to take a look at amazon memory and cpu prices and make RPs a bit more powerful than average smartphones.

Cheers,
R.

On Fri, Aug 18, 2023 at 8:05 PM Jakob Heitz (jheitz) <jheitz at cisco.com<mailto:jheitz at cisco.com>> wrote:
Perhaps to you Robert.
I work on code and with customer issues that escalate to code.

Kind Regards,
Jakob

From: Robert Raszuk <robert at raszuk.net<mailto:robert at raszuk.net>>
Date: Friday, August 18, 2023 at 10:59 AM
To: Jakob Heitz (jheitz) <jheitz at cisco.com<mailto:jheitz at cisco.com>>
Cc: nanog at nanog.org<mailto:nanog at nanog.org> <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Re: Destination Preference Attribute for BGP
Hi Jakob,

On Fri, Aug 18, 2023 at 7:41 PM Jakob Heitz (jheitz) via NANOG <nanog at nanog.org<mailto:nanog at nanog.org>> wrote:
That's true Robert.
However, communities and med only work with neighbors.
Communities routinely get scrubbed because they cause increased memory usage and convergence time in routers.

Considering that we are talking about control plane memory I think the cost/space associated with storing communities is less then negligible these days.

And honestly with the number of BGP update generation optimizations I would not say that they contribute to longer protocol convergences in any measurable way.

To me this is more of the no trust and policy reasons why communities get dropped on the EBGP peerings.

Cheers,
R.

Even new path attributes get scrubbed, because there have been bugs related to new ones in the past.
Here is a config snippet in XR

router bgp 23456
attribute-filter group testAF
  attribute unrecognized discard
!
neighbor-group testNG
  update in filtering
   attribute-filter group testAF

The only thing that has any chance to go multiple ASes is as-path.
Need to be careful with that too because long ones get dropped.

route-policy testRP
  if as-path length ge 200 then
    drop
  endif
end-policy

Kind Regards,
Jakob

From: Robert Raszuk <robert at raszuk.net<mailto:robert at raszuk.net>>
Date: Friday, August 18, 2023 at 12:38 AM
To: Jakob Heitz (jheitz) <jheitz at cisco.com<mailto:jheitz at cisco.com>>
Cc: nanog at nanog.org<mailto:nanog at nanog.org> <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Re: Destination Preference Attribute for BGP
Jakob,

With AS-PATH prepend you have no control on the choice of which ASN should do what action on your advertisements.

However, the practice of publishing communities by (some) ASNs along with their remote actions could be treated as an alternative to the DPA attribute. It could result in remote PREPEND action too.

If only those communities would not be deleted by some transit networks ....

Thx,
R.

On Thu, Aug 17, 2023 at 9:46 PM Jakob Heitz (jheitz) via NANOG <nanog at nanog.org<mailto:nanog at nanog.org>> wrote:
"prepend as-path" has taken its place.

Kind Regards,
Jakob

Date: Wed, 16 Aug 2023 21:42:22 +0200
From: Mark Tinka <mark at tinka.africa>

On 8/16/23 16:16, michael brooks - ESC wrote:

> Perhaps (probably) naively, it seems to me that DPA would have been a
> useful BGP attribute. Can anyone shed light on why this RFC never
> moved beyond draft status? I cannot find much information on this
> other than IETF's data tracker
> (https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-dpa/) and RFC6938
> (which implies DPA was in use,?but then was deprecated).

I've never heard of this draft until now, but reading it, I can see why
it would likely not be adopted today (not sure what the consensus would
have been back in the '90's).

DPA looks like MED on drugs.

Not sure operators want remote downstream ISP's arbitrarily choosing
which of their peering interconnects (and backbone links) carry traffic
from source to them. BGP is a poor communicator of bandwidth and
shilling cost, in general. Those kinds of decisions tend to be locally
made, and permitting outside influence could be a rather hard sell.

It reminds me of how router vendors implemented GMPLS in the hopes that
optical operators would allow their customers to build and control
circuits in the optical domain in some fantastic fashion.

Or how router vendors built Sync-E and PTP into their routers hoping
that they could sell timing as a service to mobile network operators as
part of a RAN backhaul service.

Some things just tend to be sacred.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230818/8bb5a6db/attachment.html>