[lisp] draft-ietf-lisp-introduction - Design Principles and Use Cases

Ronald Bonica <rbonica@juniper.net> Sat, 11 October 2014 23:51 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239661A005B for <lisp@ietfa.amsl.com>; Sat, 11 Oct 2014 16:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level:
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 o-JEgbIXMz6Z for <lisp@ietfa.amsl.com>; Sat, 11 Oct 2014 16:51:19 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD901A0049 for <lisp@ietf.org>; Sat, 11 Oct 2014 16:51:19 -0700 (PDT)
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 23:51:16 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.00.1049.012; Sat, 11 Oct 2014 23:51:16 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: draft-ietf-lisp-introduction - Design Principles and Use Cases
Thread-Index: Ac/lqvcINCyI5osOQ6Gg8d15EFfQeA==
Date: Sat, 11 Oct 2014 23:51:15 +0000
Message-ID: <a9e800cf8a2c468ab72524d182aaad64@CO1PR05MB442.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.10]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0361212EA8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(108616004)(230783001)(110136001)(101416001)(87936001)(229853001)(77096002)(85852003)(99396003)(95666004)(86362001)(85306004)(21056001)(92566001)(2351001)(76482002)(107046002)(40100003)(2656002)(2501002)(122556002)(74316001)(106356001)(20776003)(99286002)(107886001)(64706001)(80022003)(50986999)(46102003)(97736003)(76576001)(105586002)(31966008)(4396001)(54356999)(120916001)(66066001)(33646002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/nUa6-SpSQYp98Lcmqu8L5zAnHa0
Subject: [lisp] draft-ietf-lisp-introduction - Design Principles and Use Cases
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2014 23:51:21 -0000

Folks,

In Section 2.1, we say that LISP is built on top of four basic design principles:

   - Locator/Identifier split
   - Overlay architecture
   - Decoupled data and control-plane
   - Incremental deployability

However, none of these design principles are unique to LISP. The IETF has produced many overlay architectures over the years and nearly all of them share these characteristics. 

Oddly, the one design principle that *is* truly unique to LISP is omitted from the list. That is, the route pull model.

Likewise, In Section 7, we site several use cases to which LISP might be applied. However, we say nothing about why LISP might provide a better solution than any of the other overlay architectures that the IETF has produced in years gone by. Does LISP provide a superior solution because of its one unique characteristic? 

In order to fix these problems, I suggest that we make the following changes to Section 2.1:

- add a bullet concerning route pull
- add a sentence saying that route pull is the only principle that is unique to LISP

A use case should be included in Section 7 only if route pulling makes the LISP solution superior to existing solutions.

Ron Bonica