Hi Michael, > two datacenters which user traffic can egress, and if one is used we want that traffic to return to the same > data center. It is a problem of asymmetry. It appears the only tools we have are AS_Path and MED, and so > I have been searching for another solution, that is when I came across DPA.
If there are really legitimate reasons to force the symmetry I would use disjoined address pools in each data center and asymmetry is gone the moment you hit commit. And redundancy could be still accomplished at the higher layer - front end each DC with LB or use of multiple IP addresses in each DNS record. Best, R. On Wed, Aug 30, 2023 at 6:57 PM michael brooks - ESC < michael.bro...@adams12.org> wrote: > >With AS-PATH prepend you have no control on the choice of which ASN > should do what action on your advertisements. > Robert- It is somewhat this problem we are trying to resolve. > > >I was imagining something sexier, especially given how pretty "useless" > AS_PATH prepending is nowadays. > I, too, am looking for something sexy (explained below). But can you > explain why you think AS_PATH is "useless," Mark? > > For background, and the reason I asked about DPA: > Currently, our routing carries user traffic to a single data center where > it egresses to the Internet via three ISP circuits, two carriers. We are > peering on a single switch stack, so we let L2 "load balance" user flows > for us. We have now brought up another ISP circuit in a second data center, > and are attempting to influence traffic to return the same path as it > egressed our network. Simply, we now have two datacenters which user > traffic can egress, and if one is used we want that traffic to return to > the same data center. It is a problem of asymmetry. It appears the only > tools we have are AS_Path and MED, and so I have been searching for another > solution, that is when I came across DPA. In further looking at the > problem, BGP Communities also seems to be a possible solution, but as the > thread has explored, communities may/may not be scrubbed upstream. So, > presently we are looking for a solution which can be used with our direct > peers. Obviously, if someone has a better solution, I am all ears. > > A bit more info: we are also looking at an internal solution which passes > IGP metric into MED to influence pathing. > > To avoid TL;DR I will stop there in the hopes this is an intriguing enough > problem to generate discussion. > > > > > michael brooks > Sr. Network Engineer > Adams 12 Five Star Schools > michael.bro...@adams12.org > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > "flying is learning how to throw yourself at the ground and miss" > > > > On Fri, Aug 18, 2023 at 1:39 AM Robert Raszuk <rob...@raszuk.net> wrote: > >> 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@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@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/ >>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-dpa/__;!!IR39LLzvxw!LfO7m5JiQpZx6Lp-F2LQMBHi-YefsPMl8GdYkbrFSGWXd0G3HHj6wxEJv7_K0Y-_pIAyvahmJPXvcHAc251UDA$>) >>> 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. >>> >>> > This is a staff email account managed by Adams 12 Five Star Schools. This > email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender.
