Re: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-impact-04: (with COMMENT)

Luigi Iannone <ggx@gigix.net> Thu, 22 October 2015 09:21 UTC

Return-Path: <ggx@gigix.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 61AF31A0169 for <lisp@ietfa.amsl.com>; Thu, 22 Oct 2015 02:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable
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 TMpREV0q4huQ for <lisp@ietfa.amsl.com>; Thu, 22 Oct 2015 02:21:22 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 D8B341A017D for <lisp@ietf.org>; Thu, 22 Oct 2015 02:21:20 -0700 (PDT)
Received: by wicll6 with SMTP id ll6so126237499wic.0 for <lisp@ietf.org>; Thu, 22 Oct 2015 02:21:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ry8eaZ4qSaJwsRtOG9AR03Hhd7jvBVMecbMHSLN/Z3o=; b=wSR4fd4tiIO2fOjZZ/5KrkhpbVCo9eyOg+K1o3tHHhqK9DvJJfNOOrQYHKkvIduwxe 9oDjcvlWuHp+fg8Dje8bL5PNR41AQliUMtCvmfVmOBYD0dB3xvA4iQpBlW5gaBGoAdxp 3orBjryrYuRx2+QyFMSChyHi0Eron1l+fAvT5ha/MzBH968ORgsXRoTaGmvlO/cpsoMJ oN/0L2E7D2/nJnLR7k+Ys5eS0kuzdfRp7mat+WwQChZ1ZrwAqDMMIDQ/56OYj0pSax23 4sllcfT6093HEs2lEEviMgzEoENUiRhAIwa+8kj+PEXTo8wl3ZetLwuqap/WejfMyARQ dQAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ry8eaZ4qSaJwsRtOG9AR03Hhd7jvBVMecbMHSLN/Z3o=; b=SYlqoyHkTqaN7vFw48qp3iuhT/A0Q9MlDfTfg2YxF4SFLeMlfBmAoeyzJv8ZyBDzUK BIsDIJstBPECt/L5iIUBTB06e9fF+Jf54gyoC7ZAeL09zY+Nlv/Rn0A97edCfALRS2pF Bd2yTUwkByC+dVZSo4pzjJNpbKtUj0KqIHV6gTzN0GlQfSTleLgJEmEY8J3+E822ABW5 dEY5kyc/lXZRe5YRLxiM5bF6V/O59PQrYIHEqNX0BcYqJkOJ7VoXtvvLK49WC/njJpCw 2UW9li2Qn1SF+RSzfORw0wr2h9Tya4DC2Abn9RnUfi8w6ZVqvaZwtHg0QsyikcNXZZ+5 EoYQ==
X-Gm-Message-State: ALoCoQluNuyTh2Sa2DRCjuQg1rzyh11EMecnhZ62a5cFJhaBsT/pAoj4kf3fL1LiofP5tW5Si4QH
X-Received: by 10.180.93.2 with SMTP id cq2mr15464852wib.33.1445505679436; Thu, 22 Oct 2015 02:21:19 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:69d0:ed82:4a4d:120e? ([2001:660:330f:a4:69d0:ed82:4a4d:120e]) by smtp.gmail.com with ESMTPSA id w1sm15622350wjz.37.2015.10.22.02.21.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 02:21:18 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <20151021164242.13296.32356.idtracker@ietfa.amsl.com>
Date: Thu, 22 Oct 2015 11:21:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB8ECFEA-6E9B-4D05-8CE9-A7D5E6078737@gigix.net>
References: <20151021164242.13296.32356.idtracker@ietfa.amsl.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/ImV4xWWAE24dyBaFg5lMYWmV098>
Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-lisp-impact@ietf.org
Subject: Re: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-impact-04: (with COMMENT)
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 22 Oct 2015 09:21:23 -0000

Hi Spencer,


> On 21 Oct 2015, at 18:42, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
> 

[snip]
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> "RLOC" is spelled out on second use, but not on first use.
> 

Thanks for pointing this out. We have to fix this and a few other acronyms that we use first and define later.


> "Addresses are semantically separated in two:" was a bit rough for me.
> Perhaps something like "Addresses have two components with different
> semantic meanings:”?

I fear it could be misinterpreted. Is not the address that has two “components”, is the addressing space that is split in two semantically different sub spaces.

What is we out the following text:

	“Addresses are separated in two sets that have different semantics meanings”

Would that work?


> 

> In this text:
> 
>   Middle boxes/filters:  because of encapsulation, the middle boxes may
>         not understand the traffic, which can cause a firewall to drop
>         legitimate packets.  In addition, LISP allows triangular or
>         even rectangular routing, so it is difficult to maintain a
>         correct state even if the middle box understands LISP.
>         Finally, filtering may also have problems because they may
>         think only one host is generating the traffic (the ITR), as
>         long as it is not de-encapsulated.  To deal with LISP
>         encapsulation, LISP aware firewalls that inspect inner LISP
>         packets are proposed [lispfirewall].
> 
> I wonder if we're far enough along with RFC 7258/BCP 188 that we expect
> middleboxes may not understand traffic, whether it's encapsulated or not,
> because of encryption. Perhaps that's worth a thought, if not a mention.
> 

May be modifying the first sentence as follows:

 Middle boxes/filters:  because of encapsulation or encryption, the middle boxes may
        not understand the traffic, which can cause them to drop
        legitimate packets ([RFC7258]).

Would that work?


thanks

ciao

Luigi