[Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-0 0.txt

[Eric A. Hall]

on 8/21/2003 10:18 AM Tim Christensen wrote:

> At 8/21/2003 10:35 AM, Eric A. Hall wrote:

>> Furthermore, all delegations are required to be netblocks that fall
>> on CIDR boundaries, which is a single value, and is therefore going
>> to be highly efficient in terms of key-based referrals.
> 
> Not true. All delegations are _not_ required to be netblocks that fall
> on CIDR boundaries.

I'm perfectly aware that organizations allocate addres space, where the
space may span multiple netblocks, but the components themselves are still
required to be netblocks right?

Also, my understanding is that the component netblocks are the discrete
entries, while the address space is just administrative. For example,
routing uses netblocks not the whole space.

> As it happens, not only can direct delegations be off-bit, but 
> subdelegations also can (and frequently are).

These are space assignments, not the netblock delegations right?

> IMO this unnecessarily limits the querying ability that the protocol 
> supports.  To presume that someone would want to query only on CIDR bit
>  boundaries is erroneous and ignores the fact that many network
> delegations span multiple cidr-espressed blocks.

There is no such presumption. The effort is to find an efficient means of
representation so that the hierarchical delegatin system actually works.
We can support additional representations but those are by definition
going to be search-by-value and thus limited to target servers.

Also, don't forget that we have the ASN namespace as a separate hierarchy.
Each of the partitions and entries in that hierarchy would naturally
reference administrative groups, any of which could also provide pointers
to discontiguous network blocks as associated resources.

> While it's true that you _could_ choose to look at this another way --
> to consider that a multi-cidr-block delegation is really just
> contiguous cidr-represented networks, and that in and of itself means
> that the (single-CIDR-addressable block) is unique -- I see 2 problems
> with this approach:
> 
> - seems to me that most folks want to know the size&shape of the
> delegated block - it still doesn't address full-subdelegation of the
> cidr block (and indeed, creates an even larger problem in this area)
> 
> To exemplify, assume that we have a network delegation from 10.10.254.2
> to 10.10.254.254 (this is close to a real world example in ARIN's
> database, details modified somewhat).  It requires 13 CIDR blocks to
> represent this single network resource (resource from the perspective
> of a single allocation instance).  If I were to issue a query for
> 10.10.254.64, or even for the range 10.10.254.64 -> 10.10.254.240, I
> would want to know that this range is encompassed by the delegated
> network 10.10.254.2->254.  Using the 'netblock' query model above does
> not permit the latter query (since itself is a multi-cidr range), and
> the further discussion seemed to preclude identification of the network
> as a single database entry (again not reflective of reality and
> undesirable IMO)

The example you cited is supported in the default (with FIRS anyway). Each
parent netblock in the delegation path would be returned as it was
encountered during the chase-down to the query value.

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