Re: [RRG] Properties of mapping solutions

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

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.

>   2. EID->RLOC mappings published by end-site in DNS.

(a) Conceptually, I believe we need to think about generic
prefix->prefix mappings; EID->RLOC is the specific instantiation
for one particular scheme.

(b) It certainly isn't given that the mappings will be published
by the end-site. They could be published upstream, most likely by
the transit provider.

(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.

>   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.

>   5. ITRs use static mapping from (3) plus unreachability from (4) to
>      produce dynamic mapping.
>         1. dynamic mapping uses unreachability to de-prefer RLOCs,
>            rather than suppressing EID->RLOC mappings
>         2. static mappings use MX-style preference values for RLOCs for
>            TE purposes
>         3. dynamic mapping sum statics and dynamic values (1 and 2) to
>            produce well-ordered set of RLOCs (per EID of course).
>   6. DNS lookups which return RR sets containing EIDs, are used to
>      signal cache population with dynamic entries
> 
> Is this sufficiently abstract to be "conceptual"?
> 
> Does this scale sufficiently well? I think it would not require much new
> work to implement.
> The DNS stuff is nearly trivial:
> 
>    * 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.

   Brian C

>    * Include the literal label "eid" with PTR entries for all of the
>      RLOCs, pointing to ip6.arpa or in-addr.arpa reverse entries for
>      the corresponding RLOC prefixes.
>    * In the reverse mapping for the RLOCs themselves, include the
>      literal label "rloc" with a PTR to the reverse entry for the EID
>      prefix.
> 
>    Example zone file (EID reverse zone):
>    @     soa (...)
>    mx   10   <rloc1>.ip6.arpa.
>    mx   20   <rloc2>.ip6.arpa
>    rloc    PTR <rloc1>.ip6.arpa.
>    rloc    PTR <rloc2>.ip6.arpa.
>    (normal hex contents of this nibble of reverse zone)
> 
>>
>> If we push out the static mapping info (EID prefix -> RLOCs) as well
>> as the dynamic mapping info (which RLOCs are reachable) we're
>> basically reinventing BGP.
> This is true *only* if the two pieces of information come from the same
> source.
> 
> If the RLOC reachability does not come from the ETR, and/or if the
> EID->RLOCs is published some other way, then it looks almost nothing
> like BGP, except that it produces some kind of FIB.
>> This model also requires just a bare minimum of signaling between ITRs
>> and ETRs.
> I'm not sure that *any* signaling between ITRs and ETRs is necessary, or
> buys anything. It introduces an N^2 amount of state, into something
> which (ideally) scales much better than this.
> 
> Brian Dickson
> 
> -- 
> 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
> 

--
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