Re: [RRG] Run your own ETRs and ITRs, mobility, local anycast for Query Servers

[Scott Brim <swb@employees.org>]

Excerpts from Xu Xiaohu on Thu, Dec 06, 2007 02:33:55PM +0100:
> It's interesting to allow the ETR to issue the update of EID->RLOC
> mapping dynamically, no matter that the ETR is owned either by ISPs
> or by users. In this way, the burden on the ITR/mapper to detect the
> multihoming failure event can also be reduced. That's to say, the
> ITR/mapper just need to know the reachability of the ETR. Of course,
> the ITR/mapper is required to have real-time EID-RLOC mapping info.

We need to constrain rate*state in both DFZ routing (our primary goal)
and in the mapping system as well.  In most of the proposed mapping
systems, the map request answerers are not involved in real time
operations.  In order not to flood them with operational updates,
there's a tradeoff where the mapping system gives preliminary
information about ETRs that *might* be used, and then the actual
operational state of the ETRs is discovered by exchanging packets.
That dramatically reduces the amount of traffic between sites and the
map request answerers.  On the other hand, in LISP ALT, the map
request answerers are themselves ETRs.  Removing the division between
ETR and request answerer has a couple of useful results:

  - If a prefix is unreachable because all of its ETRs are off the
    air, then a Map-Reply is simply not returned.  

  - Only those ETRs that are up and running will respond to
    Map-Requests.  So if you get a Map-Reply you know which RLOC is
    sure to work.

> I don't think the full-database mapper is a good option. With the
> EID space being splitted into more slices, IMO,the distributed
> mapping/forwarding mapper is more ideal. PoP in CRIO is a good
> example. 

We can move from full to partial, or back, depending on operational
considerations.

> Of course, we can optimize the CRIO concept further by
> using anycast mechanism, this is to say, multiple PoP/mapper will be
> authoritative for some EID block. In this way, the query/forwarding
> burden can be balanced further 

Yes but ...

> and the forwarding path stretch can
> be shortened.

I don't see how that follows.  

Scott

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