D. Hugh Redelmeier
hugh at mimosa.com
Sun Oct 13 15:04:12 UTC 2019
The ip_range type seems to be used for two purposes:
- traffic selectors
- ip address pools
The two uses have diverged. Lots of complexity has been added for the
address pool case which is not clearly correct or useful for the traffic
Is there an RFC-based limit on range sizes for traffic selectors?
If so, that should be enforced (i.e. violation should be failure,
not truncation). If not, we should not trunctate them.
For address pools, I think that we get to set the rules. It seems to
me that 2^32 is large enough. That's what our code supports. Why not
treat a larger size as an actual error rather than truncating to
specified range? Then a lot of truncation logic goes away. Clearly
this limit must be spelled out in the documentation (perhaps it is --
I haven't looked).
The routines that currently do truncation don't know whether they are
dealing with a traffic selector or an address pool.
I suggest that the old ip_range type be reinstated and that a new type,
perhaps "pool_range", be added with the new features.
The pool_range type could be composed of an ip_range and some additions.
Among other things, this would allow improved modularization and
More information about the Swan-dev