Dear Job, Fredrik, 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 - 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..
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. 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. Best regards, Martijn Schmidt On 18-12-17 12:41, Fredrik Korsbäck wrote: > On 2017-12-18 11:50, Job Snijders wrote: >> Dear GROW, >> >> After the gazillionth routing incident in which an IXP route server >> amplified the problem, I think it is time we explore mechanisms to >> improve accountability, auditability & make debugging easier. >> >> It is common practise for route server operators to configure their >> route server in such a way that the route server does not append its own >> ASN to the AS_PATH attribute. Many IXPs view this practise as >> justifiable because it gives them a competitive advantage over transit >> providers. >> >> RFC 7947 reasons "a route server does not participate in the process of >> forwarding data between client routers", but meanwhile quite some IXPs >> have more equipment and layer-2 hops as part of the forwarding path than >> comparable IP networks for similar distances. [1] [2] [3] Does it even >> matter that the route server device itself is not part of the >> forwarding path? For all intents and purposes it is a BGP hop. The route >> server is not under administrative control of the RS participants. >> >> Whenever routing incidents occur, it takes considerable effort to >> pinpoint which route server BGP speakers amplified the problem. Quite >> some correlation & verification work is needed to reliably point out >> which route server at what IXP contributed to the propagation of a >> hijack or a route leak. If IXP route servers were visible in the >> AS_PATH (just like normal IP networks), I think we'd see a lot more >> responsible behavior and the implementations of route filters. >> >> Consider the following scenarios. When client A & client B at the same >> IX have a bilateral session with each other, it doesn't matter whether >> the route server injects its AS in the AS_PATH: the bilateral session >> makes the route server control-plane path irrelevant. Since it is common >> practise to assign a higher local preference to 'peering' routes >> compared to 'transit' routes, in the case that client A & client B don't >> have a bilateral session and only see each other via the route server, >> padding the AS_PATH with the route servers ASN still won't have an >> negative effect. It is only in corner cases that the AS_PATH becomes the >> tie-breaker, and I find it hard to use those as justification to >> sacrifice all of the route server's visibility. >> >> Another benefit is that if route servers behave like normal BGP >> speakers, client's dont need to disable safety checks such as "no bgp >> enforce-first-as". Or that routing policy to match on prefixes coming >> from the route server (on devices not connected to the IX) are simpler >> if the ASN is vislble, and of course the same applies to analysis of MRT >> dumps or use of BGP data in applications such as spam filtering. Or >> think of hunting down announcements that became ghost routes, without >> all ASNs visible in the AS_PATH as operator you'll be going through >> severe pains to find the ghost route perpetrator. >> >> Decades ago some argued that route servers should provide an experience >> as close to bilateral peering as possible. But fast forward to 2017, we >> see route servers with hundreds of thousands of paths, thousands of >> sessions, in essence route servers became partial transit providers. I'd >> argue that route server operators should assume their fiduciary duty and >> stop hiding themselves. This will allow both operators & researchers to >> more easily pinpoint issues, and help fix them. >> >> In summary, I think RFC 7947 section 2.2.2.1 & 2.2.2.2 were misguided, >> should be revisited, perhaps deleted. Thoughts? >> >> Kind regards, >> >> Job >> >> [1]: https://ams-ix.net/technical/ams-ix-infrastructure >> [2]: https://www.linx.net/tech-info-help/network-topology >> [3]: https://www.nl-ix.net/network/projected-core-map-2017/ >> > > Hi. > > This makes alot of sense actually. Now that we live in a world where a > route-server and an IXP is not what it used to be we need to consider > IXPs as any ISP out there. Heck, some of these IXPs runs bigger > infrastructures then most of their customers do. > > Injecting the RS asn into the path makes troubleshooting much easier > and helps us understand the routingt-able alot better, and having a RS > ASN show up when backtracking an incident on f.e BGP Play will shorten > the lead-time to figuring out what actually happened significantly. > > I do see a problem however that we kinda need to change this all at > the same time to not get very wonky routing for those relying heavily > on routeservers - this i have no idea how to coordinate. > > but should it be done? Yes it should _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
