[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Properties of mapping solutions
Iljitsch van Beijnum wrote:
On 9 jan 2008, at 20:05, Tony Li wrote:
Better yet, we should simply morph this into a more general
discussion about properties of mapping solutions.
I'll change the subject line accordingly.
What's the right approach here? Let's have a conceptual discussion
and leave out the mechanisms, please.
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).
2. EID->RLOC mappings published by end-site in DNS.
3. EID->RLOC lookups done pro-actively based on set of EID prefixes
from (1). This produces the static mapping table.
4. RLOC *un*-reachability distributed as opaque data by LIR at
aggregation point(s), into BGP.
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
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.
* 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
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)
This is true *only* if the two pieces of information come from the same
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.
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
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.
to unsubscribe send a message to firstname.lastname@example.org 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