Hi Nick, On Mon, Dec 18, 2017 at 01:04:03PM +0000, Nick Hilliard wrote: > Job Snijders wrote: > > 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. > > you missed the term "misconfigured" or "malconfigured" when describing > the route server in question.
Which route server in question? They are close to invisible. :) > > 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. > > It's also common practice for transit providers to use a single ASN > spanning the globe e.g. 174, 2914, 3356, etc. What you're describing > here is an aspect of the fact that that as-pathlen has not been a > useful determinant for the bgp decision engine for many years. A common deployment strategy is that folks connect 2 transit providers and an IXP, and uppref whatever is announced via the IXP. Since LP wins over AS_PATH lenght, I maintain that for the common use case the addition of the route server's ASN in the AS_PATH has no negative effects and quite some positive effects. > > 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. > > tbh, most don't - the vast majority are localised to well-constrained > metro areas and keep local interconnection local. It would be > unhelpful to this majority if observations were made about one type of > IXP, and and extrapolations were imposed on topologically dissimilar > platforms. I don't think smaller IXPs are any less susceptible to problems than large IXPs. In both instances it is helpful if there is visibility on what AS (and who is in administrative control of that BGP speaker) was involved. Even IXPs that indicate they apply ingress filters could suffer from software bugs (ghost routes) or filtering issues. In those type of cases having better visiblity is of tremendous value. And of course, if the AS_PATH length tie-breaker _does_ make for concerns, people can (and will) set up direct bilateral sessions with each other. > > In summary, I think RFC 7947 section 2.2.2.1 & 2.2.2.2 were > > misguided, should be revisited, perhaps deleted. Thoughts? > > Updating rfc4271 would be more productive What kind of update would you suggest? > - and getting IXPs to filter ingress bgp feeds by default. It would be great if we can easily identify which IXPs are not filtering. Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
