[LU-14288] Enhance nodemap ranges to work better with IPv6 Created: 04/Jan/21 Updated: 20/Jan/24 |
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.16.0 |
| Fix Version/s: | Lustre 2.16.0 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Neil Brown | Assignee: | WC Triage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | IPv6 | ||
| Issue Links: |
|
||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||
| Description |
|
The nodemap functionality in lustre allows sets of hosts to be described using a range of network addresses. For network types where the address is a simple integer, this seems reasonable. For IPv4 where an address is usually represented as 4 small integers, this is manageable, but not really ideal. The standard throughout IP is to use a netmask to identify a set of addresses, whether for routing, for access control, or any other purpose. For IPv6 it would be quite inconvenient to use ranges. Addresses are rarely allocated sequentially, and specifying a netmask length is much easier. Also, it is standard practice to store IPv6 address (and IPv4) in network-byte-order, so comparing two addresses to see if they are ordered (as needed for ranges) is clumsy to implement. Clearly we need to keep address-range support for existing address types, but I believe we should not support it for new IP address. Further we should add netmask support for existing address types. Internally, this would mean keeping nodemap information in a range-tree for 4-bytes addresses (as we already do), and using a netmask based structure for longer addresses. From user-space, we would add a syntax (/nn suffix) to specify a netmask. For 4-byte addresses this would be converted to a range. For large address, this would be used as-is.
|
| Comments |
| Comment by James A Simmons [ 20/Jan/24 ] |
|
Now to phase II. |