Re: IRR for IX peers
On 10/7/21 16:33, Nick Hilliard wrote: there was more to it than that. The grammar was too complicated to easily describe common policies and too limited to describe complex policies. The structure was difficult to extend when the routing became more complicated (e.g. mpls, route servers, ipv6, complex ibgp, etc). The tooling was too complicated for anyone to understand properly how it worked and too early to benefit from later additions, e.g. scripting language plugins. If it had been an easy problem domain to fix, it would have been fixed a long time ago, but it wasn't. All the reasons I tried and gave up, back in 2003. Mark.
Re: IRR for IX peers
Randy Bush wrote on 07/10/2021 15:26: it was sabatoged there was more to it than that. The grammar was too complicated to easily describe common policies and too limited to describe complex policies. The structure was difficult to extend when the routing became more complicated (e.g. mpls, route servers, ipv6, complex ibgp, etc). The tooling was too complicated for anyone to understand properly how it worked and too early to benefit from later additions, e.g. scripting language plugins. If it had been an easy problem domain to fix, it would have been fixed a long time ago, but it wasn't. Nick
Re: IRR for IX peers
>> i was hoping that, if 3130 said it is peering with martha, artemis >> would get a clue and stfu > > right. This was klunked around using the export-via and import-via > rpsl constructions (draft-snijders-rpsl-via), which never quite made > it to ietf wg adoption status. It did, however, point out how limited > RPSL grammar was :( i was an early and serious fan of rpsl; see my nanog preso from '96 https://archive.psg.com/960530.nanog.ps, yes, postscript, portrait mode, probably on acetate, not comic sans, and not magenta. as i said, early. it was sabatoged, thanks sean; though to make the point that it was not at all authenticated. it has proved useful, though far from a panacea. but i fear that scaling issues, lack of authentication, etc. discouraged work and it is slowly fading. randy
Re: IRR for IX peers
Randy Bush wrote on 04/10/2021 21:15: i was hoping that, if 3130 said it is peering with martha, artemis would get a clue and stfu right. This was klunked around using the export-via and import-via rpsl constructions (draft-snijders-rpsl-via), which never quite made it to ietf wg adoption status. It did, however, point out how limited RPSL grammar was :( Nick
Re: IRR for IX peers
On 10/5/21 09:29, Łukasz Bromirski wrote: …like a, say, „single pane of glass”? ;) Oh dear Lord :-)... Mark.
Re: IRR for IX peers
…like a, say, „single pane of glass”? ;) -- ./ > On 5 Oct 2021, at 06:25, Mark Tinka wrote: > > > >> On 10/4/21 21:55, Nick Hilliard wrote: >> >> Nearly 30 years on, this is still the state of the art. > > Not an unlike an NMS... still can't walk into a shop and just buy one that > works out of the box :-). > > Mark.
Re: IRR for IX peers
On 10/4/21 21:55, Nick Hilliard wrote: Nearly 30 years on, this is still the state of the art. Not an unlike an NMS... still can't walk into a shop and just buy one that works out of the box :-). Mark.
Re: IRR for IX peers
>> a SIX peer's customer could be the feed to RIS > Sure, but how do you describe the policy between your peer and their > customer in your aut-num?! That's not a thing. yup these rat holes are a pita randy
Re: IRR for IX peers
Hi Randy, On 10/04, Randy Bush wrote: > hi ben, > > a SIX peer's customer could be the feed to RIS > Sure, but how do you describe the policy between your peer and their customer in your aut-num?! That's not a thing. Cheers, Ben signature.asc Description: PGP signature
Re: IRR for IX peers
hi ben, a SIX peer's customer could be the feed to RIS randy
Re: IRR for IX peers
Hi Randy, On 10/04, Randy Bush wrote: > 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: toAS-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 signature.asc Description: PGP signature
Re: IRR for IX peers
>> what are others in this space doing?
>
> not using import/export lines in their RS or router configs, for
> starters. Probably you could count the number of IXPs that inspect
> import/export lines on the fingers of one hand, and possibly of one
> finger.
>
> Generally speaking, IXPs try to aim for filters based on a single
> {as-set,IRRDB set} tuple per RS client configured. If you're aiming
> for bilat bgp sessions, then this functionality would need to be
> replicated. Nearly 30 years on, this is still the state of the art.
i am not looking for the SIX to filter, though they do filtering.
my issue is
3130 --- SIX --- martha --- RIS
artemis runs off a RIS feed
martha is telling RIS MARTHA_3130 and artemis is saying that martha
is trying to hijack 3130's prefix.
i was hoping that, if 3130 said it is peering with martha, artemis would
get a clue and stfu
randy
Re: IRR for IX peers
Some IX'es set communities telling which member announced that prefix; if SIX is one of those, that can be used to automate origin verification. Rubens On Mon, Oct 4, 2021 at 2:08 PM Randy Bush wrote: > > 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. > > export: toAS-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. > > what are others in this space doing? > > [ and let's not descend into the rat-hole of dissing the IRR. i have > heard of this RPKI thing and might try it some day. ] > > randy > > --- > ra...@psg.com > `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` > signatures are back, thanks to dmarc header butchery
Re: IRR for IX peers
Randy Bush wrote on 04/10/2021 17:44:
what are others in this space doing?
not using import/export lines in their RS or router configs, for
starters. Probably you could count the number of IXPs that inspect
import/export lines on the fingers of one hand, and possibly of one finger.
Generally speaking, IXPs try to aim for filters based on a single
{as-set,IRRDB set} tuple per RS client configured. If you're aiming for
bilat bgp sessions, then this functionality would need to be replicated.
Nearly 30 years on, this is still the state of the art.
Nick
