[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Re: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism?
On 8/27/07 9:19 AM, Noel Chiappa allegedly wrote:
> > From: Xu Xiaohu <email@example.com>
> > how to avoid black-hole in LISP-CONS with aggregation mechanism?
> > ...
> > Now CDR-3 has two EID-prefixes, one is 184.108.40.206/8 with a nexthop of
> > CDR-1, the other is 220.127.116.11/16 with a nexthop of CDR-2. If CDR-3
> > receives a mapping request for longest-matching entry for 18.104.22.168, it
> > will result in a black-hole.
> Yes, this is a problem. I identified the same problem back in early July, and
> raised it with the CONS authors privately.
> > How to avoid it? Use the same aggregation granularity within the same
> > level? Or aggregation will not be available until all the component
> > EID-prefixes exists in the EID-prefix database of the aggregation
> > attempter?
> It seemed to me that the only way it can work is to have the requirements that
> all CDRs which are 'authoritative' (to borrow terminology from DNS) for a
> particular portion S of the address space i) have to all be siblings, and ii)
> have to know which sub-portions of S each of their siblings is authoritative
> for, to allow requests to be forwarded to the correct sibling CDR, if it
> arrives at a CDR which is not authoritative for the particlar sub-portion of
> S which the request is in.
Agreed. You simply wouldn't set up the CDR tree like this. In this
case you would re-home the CARs so that they hung off the appropriate
aggregating CDRs (for example, CAR-3 off CDR-1). This is an
administrative tree and physical topology isn't a limiting factor. In
fact you might expect authoritative CARs for a particular EID prefix to
be geographically separated.
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