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