IP Management Tool - Minimum Requirements

> Our internal solution does:
> 
> -> assigns subnets out of internal 'allocations' to help aggregation.
>    The LIR allocations and internal 'allocations' form a tree down to
>    the most specific assignments.

I think that this comes under designing the human
viewable data structures to store information about
the IP address space itself. I think what you have
done is a good idea, though.

As Nigel Titley pointed this out to me originally,
IP lends itself very nicely to a binary tree of 
largest free blocks. 

Lets design the data structure available to the
hostmaster.

> -> validation against 'overlapping' assignments and assignments out
>    of 'less specific' allocation bounds.

We definately need overlap detection.

> -> 'allocation pools' for flexible assignments in cases where addresses
>    for a single site are not aggregated into a single block.

This comes under designing the data structures, I
think.

> -> searching of unassigned space using a combined exact-fit/first-fit
>    strategy.

Please expand on this.

I don't want an end product that decides for you
which subnet you will be assigning. That will be
useful for people who need to migrate already used
ranges of IP address space into the tool (ie
everyone). 

QIP 4 does this, which is another reason why IMHO,
it's totally useless. (My views do not represent
anybody that Lucent can sue).

> -> heuristic net_name generation

I think that this is a lovely touch, but it doesn't
come into the "minimal requirements" umbrella.

> -> quick overview of allocation tree, also showing unassigned gaps.

 think that this will indeed be a useful feature of
any data structre we decide on.

> -> data is stored in a database that also stores routing and reverse
>    DNS information.

I don't believe if IPMT is mandated to deal with DNS
at all, at least in its first incarnation.


> no support for IPv6 so far...

IPv6 is something I'd like IPMT to eventually
support. Still, this might have to get stuck on the
back burner for the moment...


So; A summary so far:


1) We need to check for properly formulated dotted
quad format IPs:

   n.n.n.n/m where n >= 0;
                   n <= 255;
                   m >= 1;
                   m <= 32;

2) We need to check for overlaps so that two subnets
cannot overlap any space.

   We need to check for:
    (where a is frist IP in range,
           z is last IP in range)


    0 : No overlap

    a1---z1    
             a2---z2

             a1---z1
    a2---z2

    1 : Range 1 totally inside range 2

           a1---z1
      a2--------------z2

    2 : Range 2 totally inside range 1

      a1--------------z1
           a2---z2
   
    3 : Partial overlap

      a1-----z1
         a2-----z2

         a1-----z1
      a2-----z2

    4 : Perfect overlap, range 1 == range 2

      a1-----z1
      a2-----z2

    5 : Edge overlap = someone screwed up, editing
        by hand

      a1---z1
            a2---z2

            a1---z1
      a2---z2

      ie. 10.15.20.0 -- 10.15.21.0

          10.15.21.0 -- 10.15.21.255 

          (oops).
     
3) We need some kind of data structure to be defined,
so that the hostmaster can access the IP space in a
sensible way.

I reckon this should include:

    o A way of seeing the IP space - what is free,
      what is used.
    o A way of dividing the IP space into sections
      for assigning to different areas, such as
      colo, dialup etc. 
    o A sensible method of assigning free space (ie
      not always the next free block - think of
      migration). 

4) We need to think about IPv6


I hope people will comment on this summary and pummel
beat it into shape.

Nothing worthwhile ever happened by people being
polite.

Thank you very much Michael for your comments.

Guy

-- 
Guy Vegoda \ guy at vegoda.org *Please do not send html*
NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments*
Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) 
www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)