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. > 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. > 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. > 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 - and getting IXPs to filter ingress bgp feeds by default. Nick _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
