[RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism?
Xu Xiaohu <xuxh@huawei.com> Mon, 27 August 2007 08:56 UTC
Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPaOn-000371-5c; Mon, 27 Aug 2007 04:56:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPaOk-00036Y-Gm for ram@iab.org; Mon, 27 Aug 2007 04:56:38 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPaOi-0003dC-5b for ram@iab.org; Mon, 27 Aug 2007 04:56:38 -0400
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNF00I1KCT1UU@szxga02-in.huawei.com> for ram@iab.org; Mon, 27 Aug 2007 16:55:49 +0800 (CST)
Received: from x41208a ([10.111.12.94]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNF0079DCSXXM@szxga02-in.huawei.com> for ram@iab.org; Mon, 27 Aug 2007 16:55:49 +0800 (CST)
Date: Mon, 27 Aug 2007 16:55:45 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to:
To: sbrim@cisco.com, rrg@psg.com, ram@iab.org
Message-id: <000b01c7e888$0e6fe940$5e0c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acfoh0M85zztTCuTTCaI+X2LxI19HgAAJacQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc:
Subject: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism?
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org
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 RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] How to avoid black-hole in LISP-CONS with a… Xu Xiaohu
- [RAM] How to avoid black-hole in LISP-CONS with a… Xu Xiaohu
- Re: [RAM] How to avoid black-hole in LISP-CONS wi… Noel Chiappa
- Re: [RAM] How to avoid black-hole in LISP-CONS wi… Dino Farinacci
- [RAM] Re: [RRG] How to avoid black-hole in LISP-C… Lixia Zhang
- Re: [RAM] How to avoid black-hole in LISP-CONS wi… Scott Brim