Alexander, I share your concerns, but we're not really discussing ISP filtering politics, and there is a huge difference between an ISP providing a partial peering transit service and an IXP.
The difference is that an ISP necessarily makes all the decisions about what prefixes you receive as a customer, because you get a single bgp feed from the ISP. This means that the customer is 100% beholden to the ISP about the selection of prefixes that is transmitted. An IXP provides a platform and allows participants to make up their own minds about what works best for them. If party A wants to interconnect with party B, then the IXP shouldn't interfere. Same if party C doesn't want to interconnect with party D. It's their business and they can make their own decisions. The reason that IXPs are disinclined to insert the rsasn in a route server feed is that a route server attempts to replicate what you would see if you had bilateral peering sessions to all other RS clients. If the IXP operator inserts the rsasn, it's materially changing the bgp feed and breaking the rough equivalence between bilateral and multilateral peering. This is generally considered to be a bad thing, both by IXPs and by IXP participants. Regarding loop detection, this isn't an issue at an IXP RS because the RS does not participate in traffic forwarding. If you have concerns about ISP behaviour, this isn't really something that the IETF can deal with, except to say that stripping out the next-hop ASN is stupid, dangerous and likely to end up causing routing loops. No doubt the people who did this are already aware of this, though. Regarding Job's concerns, I agree that it would be more helpful if we had some easy way of figuring out if there were a route server involved in prefix propagation, but his proposed fix for this comes at a cost which I think is too high for IXPs and IXP participants. That, and the fact that it doesn't solve the root problem relating to filter deployment. Nick Alexander Azimov wrote: > Hi all, > > I'd like to share my support to Job's position, and the reason isn't > only 'transparency' or filtering (while they are worth to fight for). > > I see as the core of the problem, that one ISP MUST add its AS Number in > the AS_PATH and another ISP is permitted no to do it. Yes, one can tell > me, that IXP doesn't provide transit, it provides only local > connectivity, through L2 matrix, but does ISP becomes IXP if it provides > local connectivity? Imagine a situation when a customer has a choice: to > purchase partial transit (only customer cone) from ISP or to become a > member of IX. The price for both services could be quite comparable, but > customer is looking forward not only for lesser costs, but also for > increase its margin, and even if ISP will have all IX members as > customers, it will be less preferable because through IX the path will > have -1 hop. Some ISPs are already asking themselves a question, maybe > they can also remove their AS number, at least when announcing routes to > customers? > > And this pandora box has been already opened, I can name several ISPs > that provide transit and remove its ASN from AS_PATH attribute, some of > them are removing it even when announcing routes to upstreams. It's not > right, it violates BGP loop detection, but it has just same motivation > as RS at IXP - to make their routes more preferable, make 'virtual > direct' connections. Some of them even name themselves as IXPs. > > In BGPSec it's getting even worse with pCount = 0. There is a statement > in section 7.2.: > > if a BGPsec speaker does not expect a peer AS to set its pCount=0 and > if an UPDATE message received from that peer violates this, then the > UPDATE message MUST be considered to be in error (see the list of > checks in Section 5.2). See Section 8.4 for a discussion of security > considerations concerning pCount=0. > > Well, I can assume that some transit providers will be checking this > pCount value, but I don't believe it will be checked from the customer > side (it's even impossible for all, except direct neighbor). It can end > up with everybody setting pCount=0 and AS_PATH attribute will lose much > of its current use cases. > > 2017-12-18 20:38 GMT+03:00 Nick Hilliard <[email protected] > <mailto:[email protected]>>: > > Job Snijders wrote: > > You and Martijn appear to argue that the 'best path selection' > > component should not be fiddled with, which leaves me wondering > > whether we have any other methods to implement a track record ala > > 'this path announcement passed through RS AS XYZ' other than > > communities. Or are you of the opinion that the lack of visibility is > > not a problem to begin with? > > communities are low-hanging fruit and non-intrusive, and probably not a > bad thing to do. > > If you plan to spend time and energy dealing with the underlying > problem, i.e. routing leaks, then I'd suggest continuing to work on > getting IXPs to implement prefix filtering on their route servers. It's > laborious and thankless but will actually fix the problem in the longer > term - and it needs to be done anyway. > > Nick > > _______________________________________________ > GROW mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/grow > <https://www.ietf.org/mailman/listinfo/grow> > > > > > -- > | Alexander Azimov | HLL l QRATOR > | tel.: +7 499 241 81 92 > | mob.: +7 915 360 08 86 > | skype: mitradir > | mailto: [email protected] <mailto:[email protected]> > | visit: www.qrator.net <http://www.qrator.net/> _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
