[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] How to avoid black-hole in LISP-CONS with aggregation mechanism?
Hi all,
I have a doubt about how to avoid black-hole in LISP-CONS with aggregation
mechanism? My doubt is explained as follows:
+---------+ 1.0.0.0/8 CDR-1
| CDR-3 |
+----+---\+ 1.1.0.0/16 CDR-2
/ \\
Push 1.0.0.0/8 / \ Push 1.1.0.0/16
// \\
+----/---+ 1.1.0.0/16 CAR-1 +--\-----+
| CDR-1 | 1.2.0.0/16 CAR-2 | CDR-2 | 1.1.0.0/16 CAR-3
+---+--\-+ +---+----+
| \\ |
| \\ Push 1.2.0.0/16 |Push 1.1.0.0/16
Push 1.1.0.0/16 \\ |
| \\ |
+---+----+ +---\------+ +----+----+
| CAR-1 | | CAR-2 | | CAR-3 |
+--------+ +----------+ +---------+
1.1.0.0/24 1.2.0.0/24 1.1.2.0/24
1.1.1.0/24 1.2.1.0/24 1.1.3.0/24
As shown in the above figure, CAR-1 has two EID-prefixes, 1.1.0.0/24 and
1.1.1.0/24, and it sends an aggregated EID-prefix 1.1.0.0/16 to CDR-1. CAR-2
also sends an aggregated EID-prefix 1.2.0.0/16 to CDR-1. CDR-1 sends an
aggregated EID-prefix 1.0.0.0/8 to its parent CDR, CDR-3.
CAR-3 has two EID-prefixes, 1.1.2.0/24 and 1.1.3.0/24, and it sends an
aggregated EID-prefix 1.1.0.0/16 to CDR-2. CDR-2 sends a EID-prefix
1.1.0.0/16 to its parent CDR, CDR-3.
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.
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?
Best regards,
Steven XU
--
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