[RRG] Re: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism?

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Xu Xiaohu <xuxh@huawei.com>

    > how to avoid black-hole in LISP-CONS with aggregation mechanism?
    > ...
    > Now CDR-3 has two EID-prefixes, one is 1.0.0.0/8 with a nexthop of
    > CDR-1, the other is 1.1.0.0/16 with a nexthop of CDR-2. If CDR-3
    > receives a mapping request for longest-matching entry for 1.1.1.1, 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.

I did discuss this with the authors, and I think that was the answer, but I
can't verify that because we took the issue up on a conference call, and I
don't have notes of everything that was said there!

(Something to remember is that he CONS specification in the Internet-Draft is
really a very early draft, and so there are some issues (such as this one)
which aren't clearly covered yet.)

	Noel

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