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
_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram