Re: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism?
jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 27 August 2007 13:19 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 1IPeVX-0006e1-Vx; Mon, 27 Aug 2007 09:19:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeVW-0006dw-Oh for ram@iab.org; Mon, 27 Aug 2007 09:19:54 -0400
Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPeVV-0008PU-IX for ram@iab.org; Mon, 27 Aug 2007 09:19:54 -0400
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 21BB5872F4; Mon, 27 Aug 2007 09:19:53 -0400 (EDT)
To: ram@iab.org, rrg@psg.com
Subject: Re: [RAM] How to avoid black-hole in LISP-CONS with aggregation mechanism?
Message-Id: <20070827131953.21BB5872F4@mercury.lcs.mit.edu>
Date: Mon, 27 Aug 2007 09:19:53 -0400
From: jnc@mercury.lcs.mit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: jnc@mercury.lcs.mit.edu
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
> From: Xu Xiaohu <xuxh@huawei.com> > how to avoid black-hole in LISP-CONS with aggregation mechanism? > ... > 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. Yes, this is a problem. I identified the same problem back in early July, and raised it with the CONS authors privately. > 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? It seemed to me that the only way it can work is to have the requirements that all CDRs which are 'authoritative' (to borrow terminology from DNS) for a particular portion S of the address space i) have to all be siblings, and ii) have to know which sub-portions of S each of their siblings is authoritative for, to allow requests to be forwarded to the correct sibling CDR, if it arrives at a CDR which is not authoritative for the particlar sub-portion of S which the request is in. I did discuss this with the authors, and I think that was the answer, but I can't verify that because we took the issue up on a conference call, and I don't have notes of everything that was said there! (Something to remember is that he CONS specification in the Internet-Draft is really a very early draft, and so there are some issues (such as this one) which aren't clearly covered yet.) Noel _______________________________________________ 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