Re: [lisp] WG Last Call on draft-lisp-introduction-07
Dino Farinacci <farinacci@gmail.com> Sat, 08 November 2014 01:06 UTC
Return-Path: <farinacci@gmail.com>
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 ED75F1A00E0 for <lisp@ietfa.amsl.com>; Fri, 7 Nov 2014 17:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 edOAhXDf13gX for <lisp@ietfa.amsl.com>; Fri, 7 Nov 2014 17:06:04 -0800 (PST)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171441A00EF for <lisp@ietf.org>; Fri, 7 Nov 2014 17:05:47 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id a1so4916932wgh.6 for <lisp@ietf.org>; Fri, 07 Nov 2014 17:05:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fbYpLjw8oY5SSlKf+AuAtK2sHLVfpBugl+TGNI4p9D8=; b=EuhBAuY6FbP/PPGcE+DpmL3YgqoZrABmxrvzFjuyOgQPwCyV2xG0MarE+CgUMk1MCi IAOxCLnFMutH1AJMfmr7vK6cc6/kJofNX1mCOaeeOz2FcFFJtghdlOecH5qYN8uWBQmm g5Kuq4oyepvZdajKGuj2HTuCwniHFUrm/BL2p83PedrFBo304hLtLz2sQSm1g5DauCwU fmie5Eh9yrdzHeCiDF+jt43zk/0WKhz9rV0NMDJFHrN9r4L3WnJCxOTGGvhP5jIUhJDi XtMi73BJAHajnVEyolwni0LafI6+AQ4hebljCjvZPyElZjJudoK6Ji9XAgUjoO6YaSKf zzvw==
X-Received: by 10.194.250.41 with SMTP id yz9mr21958235wjc.34.1415408743925; Fri, 07 Nov 2014 17:05:43 -0800 (PST)
Received: from dhcp-8be2.meeting.ietf.org (dhcp-8be2.meeting.ietf.org. [31.133.139.226]) by mx.google.com with ESMTPSA id ge17sm617844wic.0.2014.11.07.17.05.40 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 17:05:42 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <85f825981b6d4fde824bf59f5233c20c@CO1PR05MB442.namprd05.prod.outlook.com>
Date: Fri, 07 Nov 2014 17:05:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A27065B-11C3-4A9C-A6F4-6D2144A4FF4A@gmail.com>
References: <6D803253-77B7-4126-8602-66E2C852E91F@gigix.net> <85f825981b6d4fde824bf59f5233c20c@CO1PR05MB442.namprd05.prod.outlook.com>
To: Ronald Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/FKzLjzz7qW9_QnCsRlV-ElwXUq0
Cc: Damien Saucez <damien.saucez@inria.fr>, LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] WG Last Call on draft-lisp-introduction-07
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, 08 Nov 2014 01:06:10 -0000
> Section 1: > - Although Section 1 talks around the issue, it does not explicitly state the degree to which LISP decouples locator semantics from identifier semantics. This could probably be remedied with a short bullet list. The list should include statements like the following: > o RLOCs have meaning only in the underlay network > o EIDs have meaning only in the overlay network, unless they are leaked into the underlay network > o The LISP edge (xTR) maps EIDs to RLOCS > o Within the underlay network, RLOCs have both locator and identifier semantics > o An EID within a LISP site carries both identifier and locator semantics to other nodes within that site > o An EID within a LISP site carries identifier and limited locator semantics to nodes at other LISP sites (i.e., enough locator information to tell that the EID is external to the site) > o The relationship described above is not unique. L3VPN relationships maintain the same relationship between IPv4VPN addresses and IP addresses Ron, this is going to confuse matters more than help. Especially in an introduction document. Plus, the statements you make can be very argumentative and quite possibly not true. > Section 3.1: > - Section 3.1 fails to mention that LISP does not maintain isolation between the forwarding and control planes. (That is, in LISP, forwarding plane activity routinely causes activity on the control plane). This omission is serious in itself. However, Section 3.1 amplifies the seriousness of this claim by stating that LISP decouples the forwarding and control planes. > - Section 3.1 fails to mention LISP’s most salient characteristics. These are: > o That the ITR maintains only a subset of the mapping table The document says there is an on-demand cache. > o That the ITR does not maintain a “default mapping” (i.e., a mapping to a hub that would forward all otherwise unmapped traffic) Yes, it can. So you don't want to mislead anyone. What is returned (or configured) can be any length prefix from /0 to /n. > o That the ITR pulls routes. This is to be contrasted with a push model (e.g. BGP without ORF) and a push-pull model (BGP with ORF) Why does it have to be contrasted? > Section 4.1 > The benefit of maintaining only a subset of the mapping table is that you conserve memory on the XTR. However, this benefit is tempered. When a XTR requests a mapping for an EID, it must receive the most specific mapping You should not judge the benefit. > for that EID plus all mappings that are covered by that mapping. We should say a longest match lookup is done, but again, that is detail that may raise more questions than help. > A consequence of not maintaining a default route is that an ITR will drop the first few packets destined to a prefix. But it can store a default route and many implementations do so. > Also as a consequence of the pull model, LISP requires additional protocol support to solve the problem of mapping staleness. In order to address this problem, the ITR refreshes routes periodically. However, there is a tradeoff. If the xtr refreshes routes too frequently, it burdens the control plane. If it does not refresh routes frequently enough, forwarding suffers. In order to solve this problem, the LISP forwarding plane provides feedback to the control plane. Processing this feedback consumes computational resources. It also presents security issues that may prevent the feedback mechanism from being deployed on the global Internet. You are starting to get defensive in your comments. This is not suppose to be "this is an intro to LISP and watch out how it can hurt you". ;-) Airplanes a very useful machines and they can hurt you too. ;-) Implementations can do all the things you say "LISP cannot do". > Section 4.2: > A consequence of the pull model is that LISP requires additional protocol support to solve the problem of ETR liveness. This protocol support can take the form of feedback from the forwarding plane or ETR probing. For security reasons, forwarding plane feedback mechanisms must be disabled when LISP is deployed on the global Internet. Therefore, LISP becomes increasingly dependent upon ETR probing, which may not scale well It is not additional, it is part of the control-plane. Have no idea what you are getting at. And please justify why this comment is helpful for an intro document? > Section 3.5: > - Section 3.5 should mention how PITRs will impact the size of global routing tables during the LISP transition period, particularly of EIDs cannot be aggregated before advertisement by the PITR No, there is a cost for any benefit. And it may not impact it as much as I think you think it does. > Section 7: > > - Section 7 should probably be the security considerations section. > > Section 8.2 and 8.3: > - LISP supports IPv6 transitions and VPN not because of the architectural characteristics that are unique to LISP, but because of the architectural characteristics that it shares with many other solutions. While it may support IPv6 transitions and VPN, it may not do so as well as existing solutions. Other solutions cannot support these features and give you multi-homing, load-balancing, multicast, and traffic engineering at the same time. Dino
- [lisp] WG Last Call on draft-lisp-introduction-07 Luigi Iannone
- Re: [lisp] WG Last Call on draft-lisp-introductio… Dino Farinacci
- Re: [lisp] WG Last Call on draft-lisp-introductio… Marc Binderberger
- Re: [lisp] WG Last Call on draft-lisp-introductio… Sharon Barkai
- Re: [lisp] WG Last Call on draft-lisp-introductio… Dino Farinacci
- Re: [lisp] WG Last Call on draft-lisp-introductio… Florin Coras
- Re: [lisp] WG Last Call on draft-lisp-introductio… Alberto Rodriguez-Natal
- Re: [lisp] WG Last Call on draft-lisp-introductio… Chad Hintz (chahintz)
- Re: [lisp] WG Last Call on draft-lisp-introductio… Lori Jakab
- Re: [lisp] WG Last Call on draft-lisp-introductio… Dino Farinacci
- Re: [lisp] WG Last Call on draft-lisp-introductio… Terry Manderson
- Re: [lisp] WG Last Call on draft-lisp-introductio… Fabio Maino
- Re: [lisp] WG Last Call on draft-lisp-introductio… Ronald Bonica
- Re: [lisp] WG Last Call on draft-lisp-introductio… Dino Farinacci
- Re: [lisp] WG Last Call on draft-lisp-introductio… Ross Callon
- Re: [lisp] WG Last Call on draft-lisp-introductio… Damien Saucez
- Re: [lisp] WG Last Call on draft-lisp-introductio… Luigi Iannone