Mailing List Archive

>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.brooks@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 <robert@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.

On 8/30/23 18:56, michael brooks - ESC wrote:

>
> I, too, am looking for something sexy (explained below). But can you
> explain why you think AS_PATH is "useless," Mark?

Because most network operators use LOCAL_PREF heavily, and no amount of
AS_PATH prepending will be able fight that with any reasonable success.

You can still achieve some success with AS_PATH prepending, but with the
way content is getting distributed around the world, it is becoming as
useful as running a Squid cache yourself these days.


>
> 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.

When you have multiple transit providers, you are really implicitly
accepting that forwarding asymmetry is now part of your life. You will
have full control of your outbound forwarding, but return forwarding
will be a coin toss.

You can guarantee this, to some degree, if you also have lots of
peering, as most peers will prefer to return traffic to you via peering
and not via their transit providers. But even this is not always a sure
thing, especially in situations where a network you are peering with is
doing Remote Peering.

Ultimately, the level of influence you have on the remote network's
forwarding decision, especially if you are not peering, is slim. Our
solution to this has been to focus on the "typically large" transit
providers, announce routes consistently to them, and ensure we have the
same port capacity to each one. Even with those attributes, we can't get
perfect load sharing, because we provide customers the ability to decide
which transit providers (and exchange points) they want their routes to
transit, or not. So the only routing we can consistently guarantee is
our own routes. We can't guarantee customers will let their routes exit
all transit or peering points, so we just make sure we have ample
capacity across all such relationships.

I understand that not all networks may have the ability to do this for
financial reasons, but if you can only afford to have one or two transit
providers, your best bet is to leverage the existing BGP tools as best
you can, even though the results will not be perfect.

Mark.

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.brooks@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.brooks@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 <robert@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.