Re: [RRG] Properties of mapping solutions

[briand@ca.afilias.info]

> On 2008-01-19 09:59, Brian Dickson wrote:
> ...
>> Quick question - where do we draw the line between concepts and
>> mechanisms?
>>
>> E.g. consider the following:
>>
>>   1. EID existence information derived from searchable whois
>>      (associated with RIR->LIR allocations and LIR->customer
>> assignments).
>
> Why is that an issue, even conceptually? We don't have a conceptual
> issue discovering the existence of end-system addresses today.

Exactly - precisely because location and identity are both encoded in the
IP address (IPv4 and IPv6).

And today, the existence is push-published in BGP, as NLRI data.
Because of the nature of next-hop and CIDR, it is by definition searchable.

Transit provider_S_, plural. That plurality introduces the potential for
errors. Having the end site being responsible (arguably with the ability
to outsource), gives control to the entity with an intrinsic interest in
avoiding errors.

It isn't a technical requirement, but helps scaling for both the system,
and for the transit providers.

> (c) Specifying DNS as the "newspaper" to be used is a mechanism.
>
>>   3. EID->RLOC lookups done pro-actively based on set of EID prefixes
>>      from (1). This produces the static mapping table.
>
> Yes, but you've skipped over how the mapping information is
> obtained in a timely manner at the point of lookup. I think
> that's the hardest part.

I would expect that is implementation-dependent mechanism stuff.
This in particular, since it will depend on how it gets used after it is
looked up.

>>   4. RLOC *un*-reachability distributed as opaque data by LIR at
>>      aggregation point(s), into BGP.
>
> Why by the LIR in particular? And how is unreachability determined
> by the LIR? Is unreachability as seen by the LIR certain to be equal
> to unreachability as seen from the point of lookup? The network
> isn't isotropic.

The presumption is (and I believe it is a valid assumption) that RLOCs are
assigned by transit providers out of PA space.

So, practically by definition, if PA aggregation is done, then
more-specific reachability within the PA block, *is* isotropic.

(Scalability on the routing space isn't achievable unless more-specifics
are *not* announced as a general rule.)

The two entities who would know about reachability of an RLOC will be the
LIR and the end-site. Either could announce this, so it's an area for
further drill-down. My gut feeling is, if the data gets carried in BGP,
then either the end-site needs something doing BGP announcements (even of
opaque data), or the LIR does the unreachability stuff. I think the latter
is generally prefered, given the global scope of any data in the BGP
system, and the expected wide deployment of this to end-sites.


>>    * In ip6.arpa or in-addr.arpa, at the prefix level to which EID
>>      delegations are done, overload the meaning of MX (which has no
>>      sensible meaning in the reverse zone) to be the set of RLOCs for
>>      this EID prefix, with preference metrics.
>
> That's definitely mechanism, and overloading a Mail Exchange record
> is definitely a kludge. If DNS is the solution, we should surely
> define a new RR type.

I agree, long-term. I am merely pointing out, that as a precursor to
requesting IANA code-point assignments of a new RR type, and the
coordination between rrg and dnsext, that proof-of-concept could be
implemented simply by use of MX.

Brian D


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg