Subject: [Idr] BGP route selection criteria - new path attribute for geographic distance when AS_PATH are equal for eBGP

From: Duleep Thilakarathne <[email-masked]>
Date: Sat, 8 Aug 2015 17:56:33 +0000

Dear all,

I analyzed full BGP routing table (541,199 routes) with two tier 1 ISP multi-homing scenario and found nearly 50% of routes have equal AS-PATH length. In this analysis It was considered, there was no route policy applied to influence local preference. According to BGP best path selection algorithm, when AS-PATH lengths  are equal, router breaks tie condition based on router internal logic. This does not grantee proper outgoing path selection.

I suggest to introduce new path attribute which carries accumulated distance information between different administrative domains. This not coincide with RFC 7311 since propose path attribute carries information between different administrative domains.

The purpose of introduce new path attribute is to introduce new parameter to BGP route selection algorithm when AS_PATH length is equal and reduce route policy configurations. eBGP scenario is considered.

Your comments really appreciated.

Regards,
Duleep T

This e-mail and any attachments may contain confidential and
privileged information. If you are not the intended recipient,
please notify the sender immediately by return e-mail, delete this
e-mail and destroy any copies. Any dissemination or use of this
information by a person other than the intended recipient is
unauthorized and may be illegal.
Mobitel (Pvt) Ltd.

---

From: brad dreisbach <[email-masked]>
Date: Sat, 8 Aug 2015 14:24:17 -0400

> On Aug 8, 2015, at 13:56, Duleep Thilakarathne <[email-masked]> wrote:
> 
>  
> Dear all,
>  

https://tools.ietf.org/html/draft-ietf-idr-aigp-07

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: brad dreisbach <[email-masked]>
Date: Sat, 8 Aug 2015 14:27:32 -0400

> On Aug 8, 2015, at 14:24, brad dreisbach <[email-masked]> wrote:
> 
> 
> 

actually nevermind, i misread your initial post.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 8 Aug 2015 22:49:10 +0200

Duleep,

Great that we have moved the discussion from BESS WG to IDR where it
belongs (assuming it belongs to IETF in the first place).

Additional points:

Point 1:

You said that your analysis is based on the peering with no route policy
applied. Just FYI there is parallel draft that enforces configuration of
policy to all peerings for both incoming and outgoing updates.

Ref: https://tools.ietf.org/html/draft-mauch-bgp-reject

As noted on BESS list bgp policy if configured can solve your problem today
with simple match and setting local preference, weight or cost community
(with any chosen POI).

It can be dynamic or static ...

Point 2:

You recommend that during best path selection - after AS PATH length check
router OS will automatically choose as best those paths with lower
cumulative ebgp boundaries RTT or cumulative distance between EBGP
expressed in kilometers or miles.

Well such lower RTT/Geo distance ebgp boundaries path may be 10 x more
expensive for tier-2 or tier-3 ... how do you explain to ISP management
that you "optimized BGP" and then they have to pay much more for peerings
from now on ?

Your suggestion does not seem to consider the most important BGP rule that
it is all about cost and policy.

Point 3:

Which path is chosen today becomes global routing decision. However if you
look at applications which need to talk end to end they have very different
characteristics.

Have you analysed Thomas work in regards of interdomain qos ?

http://tools.ietf.org/html/draft-knoll-idr-qos-attribute-15

Point 4:

Do you have any ietf draft describing your idea or is this just a free
discussion ?

Point 5:

How do you handle case of dropping more specific routes by an upstream?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - -

*Point 6 - My suggested alternative proposal: *

How about we take a completely different approach here and define a new BGP
path attribute which lists geographic coordinates at each EBGP boundary
BGP_UPDATE goes through ? Just like AS_PATH it would grow as you traverse
EBGP boundaries ...

It will be pure informational and static from BGP code pov.

However it could be quite useful in various ways for offline policy engines
in any possible ISP/SP to help with more accurate policy application to
their routing.

The coordinates may be accompanied by additional information (say a v6
address) to for example help anyone to measure the RTT from some sort of
local SDN BGP policy engine.

Best,
Robert

On Sat, Aug 8, 2015 at 7:56 PM, Duleep Thilakarathne <[email-masked]>
wrote:

>
>
> Dear all,
>
>
>
> I analyzed full BGP routing table (541,199 routes) with two tier 1 ISP
> multi-homing scenario and found nearly 50% of routes have equal AS-PATH
> length. In this analysis It was considered, there was no route policy
> applied to influence local preference. According to BGP best path selection
> algorithm, when AS-PATH lengths  are equal, router breaks tie condition
> based on router internal logic. This does not grantee proper outgoing path
> selection.
>
>
>
> I suggest to introduce new path attribute which carries accumulated
> distance information between different administrative domains. This not
> coincide with RFC 7311 since propose path attribute carries information
> between different administrative domains.
>
>
>
> The purpose of introduce new path attribute is to introduce new parameter
> to BGP route selection algorithm when AS_PATH length is equal and reduce
> route policy configurations. eBGP scenario is considered.
>
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Aug 2015 13:43:01 -0400

On Sat, Aug 08, 2015 at 05:56:33PM +0000, Duleep Thilakarathne wrote:
> applied to influence local preference. According to BGP best path
> selection algorithm, when AS-PATH lengths  are equal, router breaks tie
> condition based on router internal logic. This does not grantee proper
> outgoing path selection.
> 

There are a few issues I have with the general idea of the proposal.  Most
of the main ones of concern have been articulated elsewhere in the thread.
There are really two remaining ones I would like to bring up:

1. Incremental deployment of new path attributes intended to have global
impact, especially on something like path selection, are incredibly hard to
deploy.  This consideration is one of the biggest reasons why people get
pushback on their proposals to "how could you do this another way?"

2. "Distance" is rather vague.  As Robert points out, link capacity is often
more important than geographic distance.  And practically speaking,
operators already do some level of balancing act for IGP metrics that
account for capacity vs. topological "closeness".  

What would be interesting in your proposal is to hear why the IGP distance
tie-breaking step doesn't seem to be sufficient in your analysis.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 17:49:59 +0000

On 8/19/15, 1:43 PM, "Idr on behalf of Jeffrey Haas" <[email-masked]

>account for capacity vs. topological "closeness".

Additionally, you can’t be assure that IGPs under different administrative
domains are using the same criteria for assigning metrics. If you can’t
compare apples and oranges, you certainly shouldn’t add them up either…

Thanks,
Acee