Subject: [Ietf-not43] address issues

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Aug 22 12:05:24 2003

I'm going to try and summarize the issues we've talked about so far.

Feel free to correct/criticize these statements.

1] Netblocks (address/prefix) should be the atomic units of data in the
distributed database, for several reasons.

Netblocks have embedded hierarchical information which is sufficiently
usable as key values for distributed lookups. Administrative ranges
(start.addr - end.addr) also seem to provide sufficent detail for this,
but netblocks use a single value which is substantially easier to work
with in general.

Netblocks are what actually get delegated. When a netblock is allocated,
an associated range may get created or expanded. When the last netblock
from a range is de-allocated, the range is destroyed. Granted, the need
for a netblock is driven by a need for address space, but the space is
actually managed through netblocks and not ranges (eg, multiple ranges
used when contiguous netblocks aren't available).

Netblocks are always the smallest unit of data; an adress range can never
be smaller than a netblock. Furthermore, netblocks are often the largest
unit of data (but not always). EG, address ranges can have gaps, meaning
that they cannot always be used to represent contiguous address space.
Furthermore, netblocks can be transferred between operators as discrete
units of data (modulo policy considerations for doing so), potentially
resulting in (additional) gaps within an administrative range. As a
result, netblocks are always the smallest (atomic) unit of data, and are
often the largest unit of data.

Since netblocks are the most-atomic, they are generally going to be the
most-useful for external systems (including existing layered applications
and new ones alike). There are some UI factors here (eg, the format of a
control file), but in the general case, a netblock is going to be more
useful as the canonical representation of a network.

Entry names that use netblocks represent superiority in the hierarchy
through relatively simple comparisons of bitmasks that are easy to
compute, while address ranges require multiple operations for these same
comparisons. EG, a netblock entry name of 10.0.0.0/8 has a
single-comparison superiority to 10.1.0.0/16, although the same
relationship would require multiple operations when using address ranges.
At a minimum, an address range would require that all of the addresses
from both ranges be verified as valid, and for the ending addresses to be
verified as greater than the starting addresses, and so forth (this is
going to be even more intensive for IPv6 networks).

Cumulatively, this means that netblocks are probably the best choice as
the atomic records in the distributed database. They are simple to use,
they are mandatory from a delegation perspective and are often needed for
layered applications, they are always the smallest unit of data and are
often the largest unit of data, and they are easy to use as lookup key
values and thus easy to reference.

2] There needs to be a way to represent larger associations (ranges) in
the system as a whole.

Currently this is handled by listing the related netblocks. My suspicion
is that there needs to be different kinds of attributes for parent,
sibling and child associations in order to adequately represent the
relationships between the networks, and to provide sufficient pointers to
the users. Is there agreement on this point?

There is a caveat here that these relationships are only going to have
meaning within a specific partition of the database. EG, ARIN is only
going to know about the sibling netblocks that it has assigned to an
organization, not about the netblocks that RIPE may have also assigned,
nor any child netblocks that may have been defined by the operator of the
netblock itself. ASN data can unify some of this data, in those cases
where an ASN is actually being used and where views of the ASN routing
data is available, but those are probably going to be exceptions instead
of the norm.

3] There probably needs to be some kind of well-known client algorithm for
mapping ranges to netblock syntaxes, particularly in those cases where an
input range does not match a single netblock. This is technically outside
the scope of the protocol, but it will probably happen often enough that
we will want to have some kind of public preference for dealing with it.
>From my perspective, the easiest way to handle a mismatch like this would
be to ignore the erroneous range and just use the starting address since
that would produce all of the parent netblock delegations (and would list
all of the related netblocks), but maybe something along the lines of
trying to determine the constituent netblocks and issuing OR queries for
all of them could be made to work. This is difficult work.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: hardie at qualcomm.com ([email-masked])
Date: Fri Aug 22 12:53:59 2003

>that they cannot always be used to represent contiguous address space.

This is  a critical point from my experience.  I worked on a proposal
with a couple of other folks a while back to limit how longest-match processing
applied to "covered" addresses*, and it turns out one of the hardest things to
deal with is the reality that some of those longer prefixes were not 
deliverable
*at all* by the entities advertising the covered address.  That is, someone
advertising a /16 may have alienated a /24 within it so completely that
they do not deliver traffic to that /24; the successful delivery of traffic
*depends* on the existence of the longer prefix being in the routing table.
I think that we need to be very careful in structuring this data model
so that we can deal with that reality.  I also suspect that,
that, despite the temptation alluded to here:

(Eric again)
>usable as key values for distributed lookups.

we need to be very careful to separate the identifiers used for distributed
lookups from the data itself.  That will give us added flexibility to handle
the different types of relationships which may pertain between objects
over times.
			regards,
				Ted Hardie

*draft-grow-bounded-longest-match-00.txt is a descendent of that work,
but Russ White has been the key to the work for so long I am not even sure
why my name is still on it.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Aug 22 13:14:57 2003

on 8/22/2003 11:53 AM [email-masked] wrote:

> we need to be very careful to separate the identifiers used for
> distributed lookups from the data itself.  That will give us added
> flexibility to handle the different types of relationships which may
> pertain between objects over times.

Abstracting things like part numbers sepate from the parts themselves is
certainly an important principle in database design. On the other hand,
abstracting social-security numbers in a database of SSNs is usually
counter-productive. Addressing data falls into the latter camp, I think,
just like domain names are self-referential to the point where DNS
benefits from using them as the key values.

While we're on the subject of abstracting identifiers, I was going to make
the point that netblocks make better identifiers because they are
provider-independent, but that's not always going to be true. While it is
true that netblocks can easily move between providers (or more likely,
between operators within a provider's realm), the same is also true for
ranges albeit it less likely. Both identifiers can be bought/sold in the
scope of where such transfers are allowed.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Fri Aug 22 13:18:56 2003

> the different types of relationships which may pertain between objects

I totally agree.

-andy