[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.
Best regards,
Steven XU
-----邮件原件-----
发件人: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 代表 Dino Farinacci
发送时间: 2007年8月28日 1:46
收件人: Xu Xiaohu
抄送: sbrim@cisco.com; rrg@psg.com; ram@iab.org
主题: [RRG] Re: [RAM] 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?
The diagram has two problems:
1) You are aggregating to the same level (to CDR-3) with different
mask-lengths.
2) CDR-1 and CDR-2 need to be part of the same CDR-mesh. That is all
the CARs 1-3
are authoritative for the same length prefix and hence need to
advertise to
the same mesh upstream.
Now having said that, you could have CAR-1 and CAR-3 advertise to the
same CDR-1 mesh, but since CAR-2 has 1.2 as it's prefix, it could
advertise into CAR-3 which is a different CDR-mesh. And then both
CDR-1 and CDR-2 can advertise 1.0.0.0/8 upstream to CDR-3.
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
--
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