Hi Nick,
On Mon, Dec 18, 2017 at 03:06:56PM +0000, Nick Hilliard wrote:
> 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.
Which part is incorrect? The desire for functional equivalence with
bilateral peering, stems from the desire to be able to compete with
transit while at the same time providing a convenience service to the IX
participants (reduced workload by aggregating many sessions onto a
select few sessions). I don't view this is not a bad thing, internet
exchanges have brought significant improvements around the world.
> 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,
If bilateral sessions exist in addition to the multilateral sessions,
the point is moot anyhow. If the RS blocks an invalid announcement,
it'll pass via the bilateral session.
> 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.
It does not follows that insertion of an ASN in the AS_PATH will create
pressure to set up bilateral sessions. People have always had a choice
whether to use multiateral or bilateral or both, the set of options
doesn't change.
> 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.
Such as?
> 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.
It is quite laborious to track down which IXPs are not filtering, given
the lack of visiblity due to the AS hiding. Let's take an example from
RIPE RIS RRC03 updates.20171216.0300.gz:
TIME: 12/16/17 03:00:06
TYPE: BGP4MP/MESSAGE/Update
FROM: 80.249.208.34 AS1103
TO: 80.249.208.69 AS12654
ORIGIN: INCOMPLETE
ASPATH: 1103 7713 2914 286 34984
NEXT_HOP: 80.249.208.34
COMMUNITY: 0:65535 1103:101 1103:1000 1103:1011 2914:420 2914:1008
2914:2000 2914:3000 34307:50197 34307:60002 65504:286
ANNOUNCE
212.252.176.0/20
213.153.247.0/24
AS 7713 inadvertently announced some of its peering & upstream routes to
other peering partners. Only through manual verification with AS 1103 we
could discover that there there is no bilateral session between 1103 and
7713, but a multilateral device is hiding between 1103 and 7713. This
could further be confirmed through PeeringDB where we see both ASNs
share a common IXP, and the IXP's RS ASN shows up in the BGP
communities: "34307:50197 34307:60002".
Life would be much simpler if we can simply read off our screen:
AS_PATH: 1103 34307 7713 2914 286 34984
Kind regards,
Job
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
