Hi Randy,
so i have an AS (3130) which peers at the SIX (RSs and some direct).
in the hope that leak detectors such as artemis would stop false
positives when they see my prefixes announced customer cones of SIX
peers, i want to add the SIX peers to my aut-num: policy.
I would be astonished if artemis was parsing your import/export
expressions, but as an academic exercise...
export: to AS-SEATTLEIX-RS-CLIENTS announce AS-RG-SEA
seems clear and obvious. but
import: from AS-SEATTLEIX-RS-CLIENTS accept AS-SEATTLEIX-RS-CLIENTS
would seem to allow bill's bait and sushi to announce microsoft to me.
and i am not sure that expansive `from` clause is actually allowed.
The having an as-set in the peering-expr part is fine, but that
particular set appears to contain all of the peers' customer cones,
which is not what you want there.
Additionally it evaluates down to "any route originated by any customer
of any peer, from any customer of any (other) peer". That's not a good
filter, as you pointed out 
In order to express what you want, the SIX needs to create:
- an as-set containing the ASNs of the RS peers (not their customers),
e.g. AS33108:AS-PEERS;
and
- for each peer, a set containing that peer's customer cone, each with
name that contains the peer's ASN, e.g. AS33108:AS-PEERS:AS65000.
Then you can say something like:
import: from AS33108:AS-PEERS accept AS33108:AS-PEERS:PeerAS
The fact that the IX operator needs to maintain these sets is a symptom
of the same issue that makes it near impossible to construct sane
filters for route-server sessions: you have no idea when someone joins,
or what they *should* be announcing.
One of the many reasons you don't see us on route-servers.
what are others in this space doing?
Mostly, asking people fill-in peeringdb records, and ignoring
import/export attributes entirely.
However we use roughly the above scheme, just in case someone is
reading.
Cheers,
Ben
