Dear Martijn, On Mon, Dec 18, 2017 at 01:23:29PM +0100, i3D.net - Martijn Schmidt wrote: > I disagree. The last thing we need is for IXPs to randomly begin > applying new "inject one's own ASN into AS_PATH" behaviour to their > routeservers
Interesting use of the word 'randomly'! :) > - anything which deviates from the de-facto standard will result in a > lot of time spent with IXPs working on migrating to the new thing. > Just look at all the effort it takes to get a no-brainer like proper > ingress route filtering pushed through.. Right now some IXPs are using the IETF RFCs as a justification to not hide their ASN in the AS_PATH - and unfortunately some of them gloss over the recommendations to apply ingress filters. I don't see a need to continue endorsing a practise that doesn't benefit the Internet as whole: people cherry-pick from the RFCs, there isn't much we can do about that. But we can at least ensure that the the set of documents describes an operating mode that allows others to do troubleshooting, and ensures there is a degree of visiblity. I mentioned before, I suspect that the route server's lack of visiblity is a direct contributor to the reluctance to apply filters on route servers. We can often observe that improved transparency leads to improved operations. Participants of the routing eco system that don't hold the best interest of all other participants at heart should at least be visible so that their choices can be researched. > I'm happy that everything has finally gotten to the point where > route-servers consistently apply the AS_PATH stripping behaviour - and > I consider it a reason _not_ to participate in the route-servers if > their ASN is still visible in the AS_PATH. For example, this proposed > change would wreak a lot of havoc on those networks with a wide > geographical footprint relying on consistent route announcements to > ensure traffic doesn't experience scenic routing. During the migration > period, longhaul traffic would be all over the place as a result of > the differing AS_PATH lengths that are seen at the various ingress > points of an autonomous system participating in route-servers. I think you are somewhat overestimating the consequences. The internet is constantly in flux and peers come & go at internet exchanges and route servers. Already today you'll be monitoring for performance and deploying routing policy accordingly. If one IXP has a route server which inserts their ASN in the AS_PATH, and another doesn't (AND this affects your business), you can just as easily level the playing field by prepending the RS ASN yourself. At this point in time most route servers can be considered the equivalent of a medimum to large sized regional operator. We don't ask normal IP transit networks to strip their ASN either. A route server adding its ASN to the AS_PATH is not the end of the world - quite the opposite - it enables others to make better choices. > What I _would_ support is a semi-standardized or well-known BGP > community to indicate whether a prefix was, at some point in its > lifecycle, propagated by a routeserver on an IXP. Better yet, a BGP > Large Community so that it's not stripped by other > "community-filtering" networks before it reaches a point where the > route can be stored into a database for later forensics. Communities propagate less reliably compared to AS_PATH. Some brought up in offlist conversations that the value of a route server is that a new participant of the internet exchange will glean immediate value from connecting to the IXP. These benefits and this concept does not change one jot if the route server presents itself as like any normal BGP speaker. It would be very strange to operate under the mode that route servers immediately become worthless if 1 ASN is added to the AS_PATH. Networks that operate on a global scale will have to make their own considerations anyhow as to how they their traffic distribution. Some have a backbone, some don't. Whenever the exchange of traffic becomes a more complex question, parties are expected to set up direct bilateral sessions anyhow. Route servers being a more visible part of the ecosystem doesn't change that. Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
