[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