Hi, Feedback on suggested path changes from another operator:
I imagine that in our case having *all* route-servers consistently add their ASN would not lead to too many path changes. The changes that we will see is that we will prefer direct peerings over route server prefixes because of AS-Path length (today it is another metric that is the tie breaker, since AS-path length is equal). For our transit customers however, this may be a slightly different story because they suddenly see the direct peerings with a shorter as-path than routes propagated via route servers and may select different paths. Suggestion: I would prefer a solution that has no impact on the as-path: > On 19.12.2017, at 00:47, Jared Mauch <[email protected]> wrote: > > I do think that having a RS emit a community saying “RS_ASN:xxx” would be > of value. As mentioned in other emails, finding these edges can be quite > complex when doing operations. However, communities are very fragile when it comes to route propagation. Removing / modifying communities is happening everywhere (mostly at AS borders). I would not like to rely on BGP communities for this. We have a solution to a slightly similar problem in iBGP route-reflection. For that purpose we added an optional non-transitive attribute CLUSTER_LIST. I suggest a similar approach for IXP route-servers (ROUTESERVER_LIST optional,transitive = list of route-server ASNs that have propagated the prefix). That seems less fragile and the implementation changes are limited to the route-servers themselves. Christoph _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
