Duleep, > Then end user experiences high latency to reach destination. In such > a case, I suggest router need to consider geographic distance to > destination and select path via NTT to reach destination by default.
Question 1: How does the router know about user's high latency ? Question 2: How do you assure Internet stability where you start churning paths based on the latency of data plane ? Question 3: What you are after has effectively been solved many years ago .. it is called Optimized Edge Routing (OER) / Performace Routing (PFR) - I suggest you google for those terms. Regards, R. On Fri, Aug 7, 2015 at 2:51 PM, Duleep Thilakarathne <dule...@mobitel.lk> wrote: > Hi Jim, > > > > Please refer below example. > > > > Assume destination IP is in Asian region. Particular ISP in a different > location (Say India) has upstream peering to US POP (Say AT&T) and Asia > POP (Say NTT). If we check BGP routing table, assume it shows > > > > XX.XX.XX.XX/24 ------àAS - AT&T,AS-XX,AS-Destination > > ------àAS - NTT,AS-YY,AS-Destination > > > > > > In above case AS-PATH is equal and assume router automatically select path > via AT&T. Then end user experiences high latency to reach destination. In > such a case, I suggest router need to consider geographic distance to > destination and select path via NTT to reach destination by default. > Deciding geo distance is a challenge but there are options. Here geo > distance means shortest distance to reach IP destination from upstream POP. > Current practice is to use community strings, but it depends on upstream > ISP capability. > > > > Can you comment my idea. > > > > Regards > > Duleept > > > > > > > > *From:* UTTARO, JAMES [mailto:ju1...@att.com] > *Sent:* Friday, August 7, 2015 4:09 PM > *To:* Duleep Thilakarathne; 'Robert Raszuk' > > *Cc:* 'bess@ietf.org' > *Subject:* Re: [bess] BGP route selection criteria - geographic distance > when AS_PATH are equal > > > > Duleep, > > > > Assuming AS-PATH is equal and AS-Content different how can > you know that the internal metrics of each AS are consistent and mirror > actual geographic distances? You have to be assured that each > administrative domain applies the same metric assignment. I do not believe > this is possible when there are multiple administrative domains. > > > > Jim Uttaro > > > > *From:* BESS [mailto:bess-boun...@ietf.org <bess-boun...@ietf.org>] *On > Behalf Of *Duleep Thilakarathne > *Sent:* Friday, August 07, 2015 5:19 AM > *To:* Robert Raszuk > *Cc:* bess@ietf.org > *Subject:* Re: [bess] BGP route selection criteria - geographic distance > when AS_PATH are equal > > > > Hi Raszuk, > > > > I went through RFC7311 and my concern is different than RFC 7311. I have > 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 route internal logic. This does not grantee proper outgoing path > selection. > > > > Appreciate your concern on above analysis. > > > > Regards > > Duleept > > > > > > > > > > > > *From:* Robert Raszuk [mailto:rob...@raszuk.net <rob...@raszuk.net>] > *Sent:* Monday, July 27, 2015 2:40 AM > *To:* Duleep Thilakarathne > *Cc:* bess@ietf.org > *Subject:* Re: [bess] BGP route selection criteria - geographic distance > when AS_PATH are equal > > > > Hi Duleep, > > > > Please consider RFC 7311 and provide feedback why you think it is not > sufficient for your objective. > > > > https://tools.ietf.org/html/rfc7311 > > > > Best, > > R. > > > > > > On Sun, Jul 26, 2015 at 9:15 PM, Duleep Thilakarathne <dule...@mobitel.lk> > wrote: > > Hi, > > > > I would like to suggest to consider geographic distance when AS_PATH are > equal in BGP route selection criteria. (as tie breaking rule). Can anybody > comment on my idea. > > > > > > Regards > > Duleept > > > > > > > > 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. > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > > > 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. > 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. >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
