Re: [lisp] Current changes for draft-ietf-lisp-rfc6830bis-08

Damien Saucez <damien.saucez@gmail.com> Mon, 08 January 2018 17:16 UTC

Return-Path: <damien.saucez@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D8312420B for <lisp@ietfa.amsl.com>; Mon, 8 Jan 2018 09:16:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 9smzGK-g8sRK for <lisp@ietfa.amsl.com>; Mon, 8 Jan 2018 09:16:13 -0800 (PST)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 9CBDE1241F5 for <lisp@ietf.org>; Mon, 8 Jan 2018 09:16:12 -0800 (PST)
Received: by mail-wr0-x22b.google.com with SMTP id n9so1645335wrg.2 for <lisp@ietf.org>; Mon, 08 Jan 2018 09:16:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QdIz6xliUoTc+dXb9l3Vr0OATYgXEZ5WkGmbggEUg9s=; b=ntK9b16/y+w8baoiejtHuD5j4Dzd3g1YynJ4HDz+RCwwBf5r65fpE91x+qkNo3M+aZ bWANaWt83OxcUGlhyQHrt3vXFOZnphqrGJ4p0vcshsAmzAhqSnvXlE52ALIp+ZJmDuFw SwwFTCcEeVX/fEtXBqA2lJ9rz3eK6ZmNzPvLQpxJrX/xAE7+KHT3faUUdB1uiGhNbV+v HRd0AlKmi76RvvP5hjGTdlnGVa8LIv5J0U6Hw+eqro7srR1+XssXrkIlAcYx/tzAkp/q sCCPd0ejfLg6SNi7P7/aZsdOWxcTsONhVvv+3nyf5Iexhnl6eRxoJBX044lBFf5F8aSy DlIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QdIz6xliUoTc+dXb9l3Vr0OATYgXEZ5WkGmbggEUg9s=; b=REIYMyPbcUVzIYZhmNrFDeI4i4lAXGp63NoO2VvBEjPgw4nYGzADQ9YeUoZdhPYikH NWwylv9f9YnltRGImvZ+gaE/XI3DGFschEj5K4mc9oJtRtNbZEPBrZFm5ou/e0WO46OA GT2WQf2LTaaPLoXg1Au91qYljKDqhKDVa/V6g5C0Z36JJ8s3ARCAsYnhcT9dbFI1EBg3 8XsKjC+PmNQ8dKhL8uWCvmCGUP95nouuXv56Wj1NA55cDM1EF1FYsbV/UglDoVk6torM wF1ovj9EERRLtrtpv5qkg38eTxw2GRqxrQ07fo9YsPrh9vYdzQvVhvNAe7X0RzkJXZal +dNg==
X-Gm-Message-State: AKGB3mIu6znKVkmNw+bzHcjcSkruEiK22K39y7k+iAggQ0Z4j3+ZKzpm H7+kAoCJzJB4zRgxMVJRTQU68zfp
X-Google-Smtp-Source: ACJfBovL52XxcXLW3CNe1No9jcRWVfyRVTAb6az7AoN0jOPtXFrkNLih759iJnSL90Q3TYaFEi67nA==
X-Received: by 10.223.192.65 with SMTP id c1mr11344608wrf.58.1515431770881; Mon, 08 Jan 2018 09:16:10 -0800 (PST)
Received: from gullinbursti.inria.fr (gullinbursti.inria.fr. [138.96.193.255]) by smtp.gmail.com with ESMTPSA id e4sm14242770wmi.14.2018.01.08.09.16.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jan 2018 09:16:09 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Damien Saucez <damien.saucez@gmail.com>
In-Reply-To: <D5733FCE-0F37-45AE-BD5B-AA17953DD8EC@gmail.com>
Date: Mon, 08 Jan 2018 18:16:08 +0100
Cc: LISP mailing list list <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <52854B15-A8D8-47CA-8680-B2D673191EBA@gmail.com>
References: <D5733FCE-0F37-45AE-BD5B-AA17953DD8EC@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/X9ajgoUN1ooQ6LIWZNLvIWIZeow>
Subject: Re: [lisp] Current changes for draft-ietf-lisp-rfc6830bis-08
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 08 Jan 2018 17:16:14 -0000

Hello Dino, The List,

That’s pretty cool to see activity around the document however I am not sure the proposed
changes are really addressing the structural problem of the document.

The current document is a mix between data-plane, control-plane, and operation questions.

The chairs proposition of re-balancing the text between 30bis, 33bis and an OAM documents
is great. It would allow people to go directly to the point they are interested in. 

1. What goes on the wire: 30bis
2. Signalling procedures: 33bis
3. Implementation details, management, and troubleshooting: OAM.

So it would mean that in 30bis it would just be all what is strictly needed to allow
inter-operability between xTRs, so at the end only packet format and how to understand
fields should be there. In this case, we can abstract the xTR as just a database that
stores mapping, how mapping are managed in this database is an implementation
question that is independent of the protocol itself.

For 33bis, it would just be the format of signalling messages and how to interpret
them, when a signal is expected to be triggered.

Finally, in OAM it would be how to implement and manage a LISP system that is
constituted of the LISP control-plane proposed in 33bis and the LISP data-plane in
30bis.

To say it clearly: remove from 30bis and 33bis all what is just the reflect of one
implementation. Normally these two document should have only what is strictly
necessary for people to implement (the way THEY want) a system that would
Inter-operate with the others. 

If we look at OpenLISP and its control-plane and the deployment of LISP-Lab
that we use in production daily, we can see that the data plane and control plane
have been implemented independently (and by different teams and even
companies) and what we can say is that a large fraction of the text in 60bis
has not been used at all for implementing the data-plane, while, on the contrary
we had to massively read/use text from 30bis to be able to implement the
control-plane. Finally, people that deployed LISP-Lab had to take content
from both 30bis and 33bis to be able to have a working environment. That
demonstrates that the separation is not done properly as normally people 
in charge of deploying a network should not have to read the data-plane
specs, or people implementing a control-plane should not have to read 
data-plane specifications.

I think the proposition of moving text that the chairs proposed is very
reasonable and greatly improve the quality of the specifications and therefore
reduce the risk of misinterpretation and bugs while implementing the protocolS


Cheers,

Damien Saucez 

> On 4 Jan 2018, at 18:00, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> Is the working group okay with me submitting these changes? This was the latest update from email before the year ended. I have made most of the changes that Luigi suggested or requested.
> 
> Dino
> 
> <rfcdiff-rfc6830bis.html>_______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp