[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,
Once aggregating to the same level with same mask-lengths is
adopted, it may result in inefficient lookup. For example, CDR-11
within level-1 CDR-mesh is authoritative for 1.1.0.0/16, with
1.1.1.0/24 and 1.1.2.0/24 in its EID-prefix table, and CDR-12 with
level-1 CDR-mesh is authoritative for 1.2.0.0/16, with only
1.2.1.0/24 in its EID-prefix table. Should both of them push
1.0.0.0/8 to their common parent CDR-mesh which is authoritative for
1.0.0.0/8?

IMO, it's better that CDR-11 pushes 1.1.0.0/16 and CDR-12 pushes
1.2.1.0/24 to their common parent CDR-mesh. As long as the
aggregation does not exceed its authoritative address space, it's
OK.

It really doesn't have to push it up, the Map-Request that comes from the top of the hierarchy will just travel one additional hop southbound and then a CONS Unreachable Message with code 2 (i.e. Not Found) is returned to the requesting CAR.

That's right.  There is no need for all children to have the same
prefix lengths, and the key restriction is to stay within the
delegated prefix.

Definitely agree. But as Noel said (I'll paraphrase), you don't want a free for all where there are more specifics all over the place or you lose your benefit of information reduction.

If we let this happen, we may as well get to a push model like NERD or RPMD. So CONS is the model where we are strongly attempting to reduce information at the expense of lookup latency (but as Noel mentioned, he is trying to improve lookup latency).

Dino

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