Re: [bess] BGP route selection criteria - geographic distance when AS_PATH are equal
Hi Thilakarathne, Point #1: What makes you think that 10 ms over 1 GB ethernet peering is any better then 20 ms RTT over 100 GB ? I would really prefer to get routed over 100 GB peerings even if the RTT would be doubled. Point #2: > There is no reqirment to synchronize different administrative > domains since router itself automatically calculate value and > add when routes advertised similar to AS PATH addition > operation. Sorry to ruin your impression about power and intelligence of routers, but they only do what they are programmed to do. So Jim's point about synchronizing metrics is still valid. Of course I assume that for you the only metric you consider here are milliseconds and therefor do not bother. Imagine one operator chooses to use physical distance and other RTT. So in the new attribute you will get time [ms] vs distance [miles]. Yet one more will also use distance buy expressed in kilometers. Please elaborate how useful such comparison will turn out to be ? Point #3: As you are suggesting use of ICMP to measure RTT please keep in mind that ICMP is not high priority protocol. It may wait in the remote or local router for processing much more then the propagation delay of the link it arrived on. Point #4: How often do you plan to remeasure the eBGP propagation ? Note that today many optical long haul transmission is hidden from ASBRs. That means that your provider of long distance connection may at will reroute you via his own web of fiber which does affect RTT. So it is pretty safe to assume what you have measured yesterday today is irrelevant. Point #5: eBGP propagation may be few orders of magnitude less relevant as propagation within each AS path is traversing. And except the case of few ASes under the same administration we do not have a way to express that one today except AIGP attribute. So if you would like to continue your research perhaps looking at that aspect first may be more valuable Cheers, R. On Sat, Aug 8, 2015 at 7:10 AM, Duleep Thilakarathne wrote: > Richard, > > Yes I am referring eBGP scenario. I suggest distance calculations based on > > 1. ICMP delay between eBGP speakers. > 2. Manually configure binding to remote AS. > > > Each eBGP speaking routers need to accumulate distance value when > advertised routes to external peer.There is no reqirment to synchronize > different administrative domains since router itself automatically > calculate value and add when routes advertised similar to AS PATH addition > operation. > > > > > > - Reply message - > From: "Richard Li" > To: "Duleep Thilakarathne" , "UTTARO, JAMES" < > ju1...@att.com>, "'Robert Raszuk'" > Cc: "'bess@ietf.org'" > Subject: [bess] BGP route selection criteria - geographic distance when > AS_PATH are equal > Date: Fri, Aug 7, 2015 10:11 PM > > There might be a good point here. RFC 7311 only takes care of the IGP > metrics. But In Duleep’s example, the metrics between two eBGP speakers are > not taken into consideration. In order to have AIGP attribute to really > represent the accumulated one, the metrics on such links should be > considered as well. However, there might be some challenges or obstacles: > The way to configure one metrics on the link between two eBGP speakers > might not be consistent with the way to configure another metrics on the > another link between two speakers. > > > > Richard > > > > *From:* BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Duleep > Thilakarathne > *Sent:* Friday, August 07, 2015 8:41 AM > *To:* UTTARO, JAMES; 'Robert Raszuk' > *Cc:* 'bess@ietf.org' > *Subject:* Re: [bess] BGP route selection criteria - geographic distance > when AS_PATH are equal > > > > Jim, > > > > > > What I want to suggest is to insert item 5 (refer below items listed) to > BGP best path selection algorithm. Once AS-PATH length is equal, next we > can think on how to select best outgoing interface. If we don’t select > proper outgoing interface it will affect to latency. I am talking this > based on practical experience I have in ISP environment. There are several > options to select best outgoing interface when AS-PATH are equal. In this > case I suggest geo distance to destination. Following are options to > calculate geo distance. Router selects outgoing interface with lowest GEO > distance to destination. > > > > 1. BGP speaking router can add distance when advertise to route to > upstream similar to AS-PATH attribute. For example > > > > ABC-D > > > > Router B advertise distance AB to router C. router C advertise accumulated > distance AB+BC to router D. > > > > 2. Above distance can be configured as manual interface command or > dynamically using ICMP or similar mechanism. We can assume ICMP delay > propositional to geo distance. > > > > 3. Alternative option is to calculate real geo distance from coordinate > system. In this case we miss intermediate hops. Accuracy is not much > accurate since cable paths do not follow real coordinate bas
Re: [bess] BGP route selection criteria - geographic distance when AS_PATH are equal
Raszuk, Please find my comments inline. Regards Duleep From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Saturday, August 8, 2015 3:05 PM To: Duleep Thilakarathne Cc: Richard Li; UTTARO, JAMES; bess@ietf.org Subject: Re: [bess] BGP route selection criteria - geographic distance when AS_PATH are equal Hi Thilakarathne, Point #1: What makes you think that 10 ms over 1 GB ethernet peering is any better then 20 ms RTT over 100 GB ? I would really prefer to get routed over 100 GB peerings even if the RTT would be doubled. Your preference may correct theoretically or in a different scenario other than ISP environment. ISPs need to pay for links and link capacity decided based on the traffic requirement and several other factors. There are none pay scenarios in ISP peering but I am not going to explain as it is irrelevant to this discussion. ISPs setup multiple links with multiple capacities in order to achieve several targets. Redundancy, low latency are few of them. Further ISPs advertise IPs to all upstream in order to get redundancy unless there is no special reason. Therefore there is high possibility to select so called 10ms 1GB link than 100 GB 20ms link for particular IP blocks in ISP environment. I will try to explain the scenario I am trying to address again since you have not understand it clearly. Assume particular tier 3 ISP in Asia (say ISP A) has 10 GB link to USA POP and 1G link to Asia POP. Web hosting provider based on Asia advertise its IP block through BGP and ISP A receives web hosting provider IP block from both paths. Assume in this case AS PATH length is equal. Then how does router select best outgoing path. According to you, if router selects 10G link, all traffic route to USA and come back to Asia. It is not desired path. My proposal is to decide best path in such a scenario and not in general BGP scenario. My proposal try to prevent random route selection using new end to end BGP attribute. If router has another end to end BGP attribute other than AS-PATH , router can consider it during tie condition. Other attribute I propose is delay between AS which is proportional to geographic distance. Further this proposal may not have more significance, if eBGP peer resides short geographic distance. For example same state in USA. But this proposal more significant to tier 2 and tier 3 ISPs who have multi-homing with long distance upstream ISPs. Point #2: > There is no reqirment to synchronize different administrative > domains since router itself automatically calculate value and > add when routes advertised similar to AS PATH addition > operation. Sorry to ruin your impression about power and intelligence of routers, but they only do what they are programmed to do. So Jim's point about synchronizing metrics is still valid. Of course I assume that for you the only metric you consider here are milliseconds and therefor do not bother. Imagine one operator chooses to use physical distance and other RTT. So in the new attribute you will get time [ms] vs distance [miles]. Yet one more will also use distance buy expressed in kilometers. Please elaborate how useful such comparison will turn out to be ? I am not oppose to Jim’s point on synchronizing. What I want to highlight is that synchronizing is not required for the attribute proposed by me. present routers program to select outgoing path based on random parameter when AS-PATH length is equal (other conditions after AS length check may not have more significance). My suggestion is to change the program in such scenario. This will prevent random route selection which router programed to do. Proposed attribute can use either length in km or delay in milliseconds. This need decide and include in the RFC. but there is a relationship between delay and distance to eBGP peer . Practically south Asian ISP can achieve around 30ms two way delay to Singapore POP and 300ms to USA POP. We can find cable distance if required. Point #3: As you are suggesting use of ICMP to measure RTT please keep in mind that ICMP is not high priority protocol. It may wait in the remote or local router for processing much more then the propagation delay of the link it arrived on. I am open in this comment. ICMP or TCP delay can be used. Based on my experience even ICMP is not give big issue as most of border routers are carrier grade. 5% to 10% delay variation may not affect to route selection decision. Point #4: How often do you plan to remeasure the eBGP propagation ? Note that today many optical long haul transmission is hidden from ASBRs. That means that your provider of long distance connection may at will reroute you via his own web of fiber which does affect RTT. So it is pretty safe to assume what you have measured yesterday today is irrelevant. I propose, each border router need to check delay to eBGP neighbor every 15 min interval. If routers detects 25% de
