Re: IP namespace

[Thomas Johannsen <[e-mail]>]

> > 
> > 2) Below o=IP we have non-leaf-entries for each IP address group
> > (according to A, B, C class adresses).  [ ... ] Within the proper
> > class address you'll find all (valid) IP [addresses[ [ ... ]
> > 
> 
> (2) is much better (or at least, it is what I had in mind :-)). I'm somewhat
> puzzled by your characterizing it as an alternative to a separate hierarchy,
> because if I understood (2) correctly, you've described a separate hierarchy
> that happens to be rooted at someplace other than the root of the DIT. 

Your interpretation is right, my term wasn't well thought.

> 
> I only have one little quibble with (2) which is that I still think
> there is insufficient hierarchy. If I understood what you're suggesting
> in (2) correctly, you're proposing carving up the IP address space
> into three large subtrees, respectively for class A, B, C addresses.
> Underneath each 'subtree' is again a large flat space containing
> all addresses in that class. My objection to the large flat space are
> the same as in (1).

No, I have another thing in mind. Each network address (within class A, B, and
C)  would get its own subtree.

E.g. 1.0.0.0, 2.0.0.0, .. 128.1.0.0, 128.2.0.0, ... 192.1.1.0, 192.1.2.0 would
all be non-leafs ("sub"s). 

These non-leaf-entries are immediate subordinates of the "IP namespace root"
and hold themselves only leaf entries (node-IP-addresses). 


                        o=IP (or whatever you like)
                                 I
        +------------+-----------+----------------------+
        I            I                                  I
   sub=1.0.0.0   sub=2.0.0.0  .....sub=128.1.0.0......sub=240.3.5.0 ...
       I                                I                  I
    +--+------+                  +------+----              I
    I         I                  I                         I
IP=1.0.0.1 IP=1.0.3.5 .......IP=128.1.5.16............ IP=240.3.5.117 ...


> What little thinking I've done on this subject has however been along
> the lines of (2) except that I want to carve up the namespace into
> a hierarchy so that subtrees corresponding to a IP network can be delegated
> to the 'owner' of the network assignment. 

And here we meet on the question of delegating each subtree to its owner (might
he run a DSA or not).

> 
> 	(a) that scheme has a lifetime that will hopefully
> 	    be measured in months due to the big-internet work
> 	    on classless, enormously scaleable IP addressing and
> 	    routing. There are already discussion within the
> 	    DNS context as to how to carve up INADDR.ARPA in the
> 	    future, and by going this route, we're essentially
> 	    investing in a scheme that could easily be obsolete
> 	    by the time it is deployed.

I've heard there is something going on. Making IP addresses classless should not
be a problem for the scheme. I'd appreciate any structure telling me what a
subnetwork is and expressing this in the name. 


> 	(b) you end up with interior nodes like 192.0.0.0 and 
> 	    128.0.0.0 which don't really 'belong' to anybody but
> 	    are instead public resources. This is a minor problem
> 	    which could easily be handled the same way we're handling
> 	    the infrastructure between national nodes and organizational
> 	    nodes (in the case of the U.S. these would be the 
> 	    U.S. state/equivalents and the U.S. counties within states),
> 	    but is a problem nonetheless.

There should be some network center doing the maintance. But actually I didn't
think about that problem before.

> 
> 	(c) by representing IP addresses by their byte components,
> 	    some semantic information is lost, for example the
> 	    fact that 128.1 (just to pick an example) is a network
> 	    in its own right, and that it is not the case that
> 	    128.1 is a subnet of a larger network 128.0.0.0. This
> 	    only gets worse when the Internet stops 'hard coding'
> 	    in distinctions between network-component and host-component

To stress my point once more: I'm *not* going to have a multilevvel tree like

            1.0.0.0

     1.1.0.0  .....       1.2.0.0.

  1.1.1.0     1.1.2.0   .. 1.2.1.0 ...
  
1.1.1.1  1.1.1.2 ...

because there is no use in asking "what belongs to 1.1.0.0". 

I hope I made myself clear now. Sorry for the not very well chosen explanation
last time :-)

> [That said, this is still closest to the ideal for me, since I can't think
>  of anything better at the momement.]

Does anybody come up with a better solution?

> 
> Wengyik
> 


Thomas