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

Luigi Iannone <ggx@gigix.net> Tue, 09 January 2018 15:06 UTC

Return-Path: <ggx@gigix.net>
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 DF78C12D86A for <lisp@ietfa.amsl.com>; Tue, 9 Jan 2018 07:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.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 NW7brxxQP_3I for <lisp@ietfa.amsl.com>; Tue, 9 Jan 2018 07:06:21 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 67FA912D868 for <lisp@ietf.org>; Tue, 9 Jan 2018 07:06:21 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id f206so21213129wmf.5 for <lisp@ietf.org>; Tue, 09 Jan 2018 07:06:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BMlJ//Pv1ckpdMwKZh1zxi1YOsrbP0dYCgS7MpcDsNo=; b=DAG+h4YBmzOOAoef8wLI/lW4XPsVhF+leX5CcC4mI6ZA273xFBEOuIhkwVbKFdUbwG yKwpF8rGWB0x6jmafeGnMKuvOZexwgbKyzO0N0Wx28h0flFHHi9yuop3iuqtdPoGUlO3 VWXsROfXh0xFWWCIg+7mroaA3oR5W3Q9GErxROGlfY7MDKxPU4BPnop4A5OF0Nj/rWAm +0ZEc2k5BKCkF9BVTNDY+RGjEBYTlflljFcem4GODkyiatho8s73o7q5p2iPoK7fOA+U LiaGPHQ/3QotULGqB2mUkpugMH3Tkw2QC3HwubrFEfuKHx3yGpzuElT5B02mKJsElUyU g64g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BMlJ//Pv1ckpdMwKZh1zxi1YOsrbP0dYCgS7MpcDsNo=; b=mhhUliS6HNzTDW6fMlBkqKToGtQRYifshcOmkF2/hOr8mTqHk+NMeRexN4BpnZVQOn obJrTlBDF8MXteNnY/9n9Ag9XVjkkxLlIF26sM4x7YxehR3rOGW1VAVooJbcu/0rNMJ3 xvKWsda7kbK6msGDCY7lRnxFI87Pdm3bkgfZZRqViTh2xI3O4M76eUuANF5CMFqFr/jT AXAGb+LtA3GGd/psRfTwuA1CytNfU40uMnIo415l4S4qCMIZXTz5PtzPrxjNYFAabW6Z lAFTo21eogO3VK+PhO9O2K3nnJiyHP8/y+WYhbjJuHjJkpERvNUJ1zMvQKzGMRIm7vRM Trlg==
X-Gm-Message-State: AKGB3mIpcMR8cUJWdlb2o0ZVXw+Obm5XzBzsnUnBajtQOdiJSSqsSAcX zBAi2wM6/eIgz7NyTMwNqmwLzA==
X-Google-Smtp-Source: ACJfBovDf97yJMFMLWSJGgeqhBT/19W5SVjXdy92lz+q+c9UHHjp9lgSAf6gA7wUmqGS5E6I9E/1VA==
X-Received: by 10.80.225.8 with SMTP id h8mr21418063edl.194.1515510379805; Tue, 09 Jan 2018 07:06:19 -0800 (PST)
Received: from ?IPv6:2001:660:330f:a4:c4aa:2fae:3f8:10d4? ([2001:660:330f:a4:c4aa:2fae:3f8:10d4]) by smtp.gmail.com with ESMTPSA id e12sm1053849edm.42.2018.01.09.07.06.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 07:06:18 -0800 (PST)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <A07F68A8-A701-4E53-87C9-65FB0FFFF508@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_54A26568-0E9E-48F8-86B3-B3046D68992B"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 09 Jan 2018 16:06:58 +0100
In-Reply-To: <CAGE_Qeww-bFo122rc+XZQnQyzza0nC=BO2H+sg_FHz_Z+4dXEA@mail.gmail.com>
Cc: LISP mailing list list <lisp@ietf.org>
To: Albert Cabellos <albert.cabellos@gmail.com>
References: <D5733FCE-0F37-45AE-BD5B-AA17953DD8EC@gmail.com> <52854B15-A8D8-47CA-8680-B2D673191EBA@gmail.com> <DD4AAA1D-779C-444F-9C23-50CCA9935693@gmail.com> <CAGE_Qeww-bFo122rc+XZQnQyzza0nC=BO2H+sg_FHz_Z+4dXEA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/4RrcdYvlZhWOewlUIsDYle2-yYU>
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: Tue, 09 Jan 2018 15:06:24 -0000

Hi Albert,


> On 9 Jan 2018, at 00:27, Albert Cabellos <albert.cabellos@gmail.com> wrote:
> 
> Hi 
> 
> As far as I remember we didn´t agree on 3 documents, this does not necessarily mean that it is a bad idea.

:-)

> 
> I still think that SMR should be on 6833bis, it is important to standardize a control-plane that includes the capability of updating EID-to-RLOC mappings.
> 
> Regarding sections Multicast, Mobility and Traceroute considerations they could be easily moved to an OAM document, but it is quite complex to properly contextualize such sections in a single standalone document. Do they have value without the context of 6830bis?

Probably not, but the point is that if you implement 6830bis you do need to read OAM stuff. 

Obviously the other way around is not true. If you want to understand LISP OAM you need to have a good knowledge of both 30bis _AND_ 33bis, _YET_ this does _NOT_ mean we need one single document for everything.

Romans used to say "dividi et impera”…. 

Ciao

Luigi


> In my view they are better in 6830bis.
> 
> I would like to hear other opinions from the list
> 
> Albert
> 
> On Mon, Jan 8, 2018 at 7:22 PM, Dino Farinacci <farinacci@gmail.com <mailto:farinacci@gmail.com>> wrote:
> Do you think it is okay to capture the changes we have made and agreed upon so far so we can submit -08 and wait for other WG members to comment on this issue?
> 
> What you are suggesting is a lot change that what was previously agreed upon. No one was really in favor of having a third document (your OAM reference below (3)).
> 
> Also the chairs didn’t suggest any changes, it was Luigi (acting as a document shepherd). I am not sure the same comment came from Joel, either publicly or privately.
> 
> Dino
> 
> > On Jan 8, 2018, at 9:16 AM, Damien Saucez <damien.saucez@gmail.com <mailto:damien.saucez@gmail.com>> wrote:
> >
> > 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 <mailto: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 <mailto:lisp@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>
> >
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org <mailto:lisp@ietf.org>
> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp