[retronet-core] [retronet] RetroNet globally-routable address allocation policy

[Grant Taylor]

On 09/02/2018 10:21 AM, John P. Willis wrote:
> I'm currently tying network number assignments to usernames:

I'm assuming that there is a direct one-to-one relationship between 
member usernames (a.k.a. nicknames) and (what I've been calling) their 
member number.

> Each network is keyed off of first its protocol/class (ASN, IPX, 
> APPLETALK, etc.) and then the network number, with a separate index 
> tying them to user accounts. Every network number assignment (including 
> ASNs themselves) has a parent ASN.

I've not had enough caffeine to follow what I think is the underlying DB 
(?) structure that you're talking about there.  —  I'll trust you until 
I have a reason to ask more.

> Keeps the code for assigning networks nicely general.

ACK

> Space isn't an issue unless network numbers exceed 17 digits.

I'll be pleasantly surprised if we run into that problem.

> If we want the user's ASN (or member number) and network numbers in 
> other types of networks to match (at least for the first allotment to 
> any user), the incrementing of next-available numbers would need to be 
> in lock-step.

I've done a little bit more thinking about this and I think that I like 
the idea of member numbers defaulting to a monotonic incrementing number 
by default, but optionally providing the number a user requests if it's 
not already in use.

I'd like to reuse said member number for as many things as possible.

In the cases where people need a second network number, default to a 
monotonic decrementing number by default, but optionally  providing the 
number a user requests if it's not already in use.

> [nerdy_programming_note]
> 
> FWIW, the code for allocating network numbers is, of necessity, reentrant:
> 
> It locks a critical section to avoid race conditions that would happen 
> if two users attempt to increment the counters concurrently.
> 
> [/nerdy_programming_note]

Okay.

I don't know enough to understand the elegance of what you're saying.

I naively would have tried to use some sort of autoincrementing filed in 
a DB.  But that doesn't account for members requesting a specific number.

Unless the autoincrementing counter (sequence) is independent of the 
table that stores information.  There would have to be some logic to 
make sure that things didn't conflict.

This is why I leave these types of things to other people.

> SGTM

I'm taking it that it's decided that members will get a single ASN.  We 
can discuss this more in the future if we need to.  Correct me if I'm wrong.

> It could be done, with non-trivial (but not extensive)  rearchitecting 
> of the network allocation code.

I'm both curious and want to stay out of those details.

> As I understand it, the IPX "internal network" number is for the purpose 
> of simplifying routing when a NetWare box has more than one physical 
> network interface.

Okay.

> AFAIK, we're only assigning external networks. I don't know what the 
> ramifications would be of assigning an external network number that 
> happens to coincide with the [usually] randomly-generated internal 
> network number of some machine on the member's network. I would hope 
> nothing, as it seems that Novell would have been in trouble with their 
> customers for such potentially-damaging nondeterministic behavior.

I believe that NetWare probes to see if the network number is in use 
during the installation specifically to avoid problems.

Remember that we're assigning a /24 for IPv4 and /48 for IPv6, either of 
which allow members to have multiple networks routed through RetroNet if 
they so choose.

That's why I was liking assigning the high 16-bits of the IPX address 
and allowing the member to assign the low 16-bits.

Granted, we could shift the divide to something like 24-bits to RetroNet 
and 8-bits to the member.  But that's somewhat of a nuance if we go with 
that idea.

As for programming, I'd think if we treated the high 16-bits (for the 
sake of conversation) as separate -or- the lower 16-bits (…) as Don't 
Care, I think we could (re)use counters / sequences that are the member 
number.  (I may be way out in left field.)

> This seems to indicate that we're allocating in hex. I've been doing 
> everything decimal.

I think this is a representation issue.  The counter is 16-bits.  I 
don't think it matters if it's four hexadecimal digits, two bytes, or 
one 16-bit int.  Maybe I'm wrong.

> What I like about the approach is that it would keep any members' own 
> networks contiguous, and would mean that we would not really need to 
> support user requests for more IPX networks (they get what they get).

Yep.

> The downside is complexity of implementation from my side ;-)

Sorry.

> I'm sure I could figure it out, though.

As long as you know that it's something you need to do.  Yep.  Hence why 
we are discussing.

> This top-down approach for user-requested allocations, with bottom-up 
> for automatic allocations would certainly make the code easier to reason 
> about and implement (other than some possible bit-twiddling if we go 
> with your idea for dividing up the IPX address space).

;-)

> I'm going to try to play with X.25-over-IP stuff in IOS in the lab this 
> week.

Cool.

I'll try to do some reading and hopefully learn enough to offer some input.

> SGTM

ACK

> A /48 would be the smallest block I'd want to dish out as well.

ACK

> Ditto.

ACK

> Perhaps we should only auto-allocate ASN and IPv4/IPv6 space, and make 
> the other stuff entirely on user request?

I'm not against that.

I'd like to sort of earmark addresses that use the member number for the 
member if possible.  Hence why I'm okay with allocating them for 
protocols that give us 16-bits (or more) of addressing space to work with.

> How married are we to having network numbers in all protocols line up 
> with member numbers?

I don't think it's a requirement at all.

I do desire it.  My brain likes patterns like that.  But I can also tell 
(that part of) my brain to take a hike.  —  I'm MUCH more interested in 
this working than appeasing the CDO part of my brain.  (It's like OCD, 
but in alphabetic order.)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.chivanet.org/pipermail/retronet-core/attachments/20180902/e348eb29/attachment.bin>