IETF Logo Mail Archive

Re: [Ideas] [lisp] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

Dino Farinacci <farinacci@gmail.com> Wed, 28 September 2016 20:30 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884D012B4A4; Wed, 28 Sep 2016 13:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOPbMFHYFr4X; Wed, 28 Sep 2016 13:30:14 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC32F12B2E1; Wed, 28 Sep 2016 13:30:14 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id s13so20831165pfd.2; Wed, 28 Sep 2016 13:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1bzZKdccEQlYzQYoQTBE1g1vaWdiiQDFahgs1l0uuUY=; b=eNNOyIVgHfLuVcmRDHl9/SH6o/DZKPe599U5D5dx8X0uFTAJ5r4Qzp/J6kzcr64+P0 0kc1+/lLrKZX6AdCqoX9pzWJ9IaWP0AovNJX4A58NVNVmdpQ17avA8LNRGqTUjSYgfxH CwqI0vOSvlZ3x8HW8sZYmBcyTz+mMb+7Vfmbomq7CkIsB/mW9/hrC2q5SmQuNap2KFZh mV+w14yEbC5wMIpAyW9W8HRfSnrch4AWy8NcHpq1KG2wCfk6C3UFOYWq25gtNL16FzUw T/0KUmdFCeKyLTRRyQkdpeffh0/0FasOjvRFEcUYvoK8GdJb4xZRrubfnwxdsN1wGgDC YDAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1bzZKdccEQlYzQYoQTBE1g1vaWdiiQDFahgs1l0uuUY=; b=d9oO+1Na+R/XSx7lQJhK1yEdJF1qYRlQfFe0RkA7LK/kA6HQL58s2X9NqlyJFxe7fA De7eqyrq/dk1uA4l0CleSGF0ipfCOEKyqew8T9MURRVT7qwRGnkmao4ct3l5JMQRv8N0 TRpKKmNVQK5Va9oeB9rve5Hs1gjcSexE+ACD3Yb4t0AEXGdGk/oJZg3IpQPGNQw14eFi yvwdqGO7M1Yv0Kjs83OQ7TULeUoo86OuEo5Wg4h3+8eHjYNyOY/5rC9tOijNUWqyb2kX 5bKiHIvgEiJqfOb6ddPpOzAgMadLl+BjUAzdS6joaP9m6QuvcxzsLOagbyBdj++lXjeI pVlA==
X-Gm-Message-State: AE9vXwOc9KGcoIiGoJpUJKINmB3HYAfYVy70HE+UZnM+qewzrFvt+N6TbZm3fXsOh3kH6w==
X-Received: by 10.98.31.133 with SMTP id l5mr60005964pfj.178.1475094614248; Wed, 28 Sep 2016 13:30:14 -0700 (PDT)
Received: from [10.197.31.157] ([216.216.202.69]) by smtp.gmail.com with ESMTPSA id t5sm14581998pfi.26.2016.09.28.13.30.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Sep 2016 13:30:13 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <57EB684E.1000601@uni-tuebingen.de>
Date: Wed, 28 Sep 2016 13:30:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D080DFDA-7CCB-4ABB-8D62-1505072DD739@gmail.com>
References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> <CA+b+ER=JhWHkDWgJhwpxUs8MWHr_yuRvqSeWgMuaJofkX_5QVg@mail.gmail.com> <8CA89FA5-D1AC-4D3B-8CB4-FD5E16DE8C4F@gmail.com> <57EB684E.1000601@uni-tuebingen.de>
To: Michael Menth <menth@uni-tuebingen.de>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/xzRFO0yjrchzzWJBrsOhob2J388>
X-Mailman-Approved-At: Thu, 29 Sep 2016 15:46:55 -0700
Cc: "beta@lispers.net" <beta@lispers.net>, "ideas@ietf.org" <ideas@ietf.org>, LISP mailing list list <lisp@ietf.org>, Robert Raszuk <robert@raszuk.net>, NVO3 <nvo3@ietf.org>, "lisp-alpha@external.cisco.com" <lisp-alpha@external.cisco.com>, LISPmob <users@lispmob.org>, "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" <lisp-ops@external.cisco.com>, Lin Han <Lin.Han@huawei.com>
Subject: Re: [Ideas] [lisp] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2016 20:30:16 -0000

> Am 28.09.2016 um 05:02 schrieb Dino Farinacci:
>>> When I spoke to some of the 5G folks this was clearly the direction and in fact Dino's LISP was one of the strongest candidates there as control plane. 
>> The IETF’s LISP-DDT borrows ideas from DNS but does not need to be structured like the DNS deployed today. There is hierarchy for scale with iterative lookups, but we don’t have to allow it to get out of hand with too many levels of hierarchy.
> What do you mean by that exactly? What's the problem with DNS and what's
> the advantage of LISP-DDT?

These were the main reasons we didn’t consider DNS as a mapping system back in the RRG days when we were designing the mapping system for LISP:

(1) DNS didn’t work easily on bit boundaries. So delegation would have to be on byte boundaries and that restricts the flexibility of how EID address allocation occurs on the LISP-DDT hierarchy.

(2) DNS doesn’t have a pub/sub model. LISP needed notification support so old RLOCs new when an EID has moved to a new set of RLOCs.

(3) Architecturally, we didn’t want routing information to be in an applicaiton Directory. Since DNS depends on routing, we didn’t want routing to depend on DNS and cause a circular dependency to be created.

(4) And we thought it would be too hard to get IETF to allow network layer information to be stored in what is really a application level database.

So the architectural definition of a LISP EID would be in the DNS pointed to by names and the dynamic binding of EIDs to RLOCs would be in a new network layer database, which we refer to as the LISP Mapping System.

Dino

> 
> Michael
> 
>> 
>> Dino
>> 
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp

v2.8.7 | Report a Bug | By Email