So, yes. RPSL did try the set theory thing and in theory this idea could
be workable, maybe.
Flicking back through rfc2622, I'm reminded of the horrors of
mbrs-by-ref. I know it's inexcusably poor taste, but I can't help
wondering whether you should also include a excl-mbrs-by-ref? Probably
better to leave this for an April 1 RFC.
Some blue-sky, stream-of-consciousness thoughts:
Firstly, any output is going to be acutely dependent on how
draft-romijn-grow-rpsl-registry-scoped-members operates. I haven't got
to that yet in my ietf draft consumption backlog, but my first thoughts
would be that the source:: scope would need to be applied aggressively
to child objects (maybe it is already).
There's plenty of scope for exclusion to create operational problems.
E.g. what happens when you have different sets which reference each
other and then one of them is configured to include the other as an
exclusion? There's no shortage of foot-guns here.
A complete set theory implementation would ideally include operators for
union, intersection, complement and all that. You can synthesize it
kinda with a simple exclusion mechanism, but I wonder about data
consistency and general flexibility.
There are two main problems with RPSL. One is grammar flexibility, of
which there is very little, which is why any extension needs a new key
mechanism defined. The second is that it inherently requires symbolic
expressions, which increases the complexity of the parser.
So, if I were approaching this - which I'm not - I'd might be tempted to
look at this from the point of view of pure set theory and design a key
which allowed complex set manipulation grammar. I.e. create a full
mechanism for symbolic manipulation of as-sets. Any existing code
implementation already needs to deal with a good deal of symbolic
manipulation, so this may not be as problematic as it seems at the outset.
I'd also ditch extending route-set objects - no-one uses them really.
Also draft-romijn-grow-rpsl-registry-scoped-members does not apply to
route-sets, so you'd have a lot of work to do if you wanted to make this
work properly.
Nick
James Bensley wrote on 15/04/2026 17:46:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Dear Working Group Members,
Please find below a newly submitted document: "Explicitly excluding objects from
RPSL sets".
The purpose of this document is to address the issue faced by many operators
today; namely that AS-SETs and ROUTE-SETs contain member entries which are
undesirable for one reason or another, but the set owner has no method to
exclude these unwanted members from their own set because they are deep within
the set hierarchy.
I have spoken to several people in the community who suffer from this problem
and would like something done about it. In the long term we hope to phase out
IRR based filtering, but we are many years away from that, so in the mean time
we’d like to improve the situation until such time.
Feedback and support from the community is appreciated.
https://datatracker.ietf.org/doc/draft-bensley-rpsl-exclude-members/
https://www.ietf.org/archive/id/draft-bensley-rpsl-exclude-members-00.html
With kind regards,
James.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail
wsG5BAEBCgBtBYJp38DUCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jnx8IJuTw/8rwqhuttwtzev2/G6pRZyujogxsc
gPMJ50MWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAi9cP/RJhqcE0KUP9QR8s
/Q6S2iMBdn78ay9AlacMzyvH2rT5/9f9ld6X3WI10/TFAvYaTpk57KeRZDL2
wwJZagIusJ1K4uhxDTzKU8OYLE3buH1+2U5kysxBmmW3nQQzdvPkAGFKaAhl
5Hpxd0q59p8RsmaumBRIWbDOHYq3YA6Ps3CNoBS2zh3hx6LDEDzm0Kr8g6El
CkFdBq2rQFuvq8ZLR8nQ1aUhFGS7G1xxPES/2jLOjnf1A9E8Fp//QsP1FONN
OttVKHFVaSbV72Cp3H1+qAqlcJ+qlZ0xAH2R6bAYQUbC+rU09LhYSF1q1krq
IfZCvoHgrg6f5xkjOZH4yau3i17hEL/8yBTaYxMeNiCQE7BT4yd5YTMhgHKw
RdjNJlS29i1ksYcB4cUNrx41JWUt8m/XRvY5tLfI277gWlPasehRfRXvebVF
T/Gha3ar5FeXVgtnkl5suH4vYdjI8RaRcA3wqrXs/oGDkzl73Zjp/FXdNUQc
Z1xK2XqjgPnL6AQkL4Ybh+5BR0pOePladBwB+dxWeE05GF0HMfBsJCKw20Yc
T/xQP0WJU6ZPKG1ET8RNKdpIA93tHthHymU+MWC//dUdB6+uZlmv2GlC2Y2T
+2dSe3iKvpo0/l4uiWM9OccJ7UYkk8De420E9XRxMyCypQyf1VVb0GgLCAFN
xXxR8fO/
=AkAY
-----END PGP SIGNATURE-----
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
