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

From: Xu Xiaohu <[email-masked]>
Date: Mon, 27 Aug 2007 16:50:05 +0800

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

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Aug 2007 10:46:09 -0700

>        | CDR-1  | 1.2.0.0/16 CAR-2           | CDR-2  | 1.1.0.0/16  

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

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 27 Aug 2007 15:01:33 -0700

Dear Steven XU,

Please do not double-post to both RAM and RRG lists.
Per my earlier message, please carry out this discussion on RRG list.

Lixia
(RAM moderator hat on)

PS: to subscribe RRG list, send mail to [email-masked] with the  
word
"subscribe" in the body of your email.

On Aug 27, 2007, at 1:50 AM, Xu Xiaohu wrote:

> --
> to unsubscribe send a message to [email-masked] 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