Job Snijders wrote: > 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.
This is both incorrect and mildly pejorative. The justification for stripping the RS-ASN is that multilateral peering is (mostly) functionally equivalent to bilateral peering. If the RS-ASN is injected into the AS path, then they become substantially non-equivalent, and bilateral peering sessions become preferred. This is not ideal: it's extremely unusual for bilateral peering over an ixp ever to have any filtering, so if you push IXPs to inject the route server ASN, this will create pressure to implement more bilateral peering and consequently more problems in the longer term, which are effectively impossible to deal with. I can see why you think that injecting the rsasn into the as-path is alluring, but be careful what you wish for, because fiddling with this will have consequences which extend far outside your assumed scope. At least in most cases, it's pretty straightforward these days to implement route servers with full, dynamically rebuilt filtering out of the box. The technical work has been done. What's left is to get the remaining IXPs which don't filter their inbound prefixes to deploy this. Nick _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
