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

Albert Cabellos <albert.cabellos@gmail.com> Mon, 08 January 2018 23:27 UTC

Return-Path: <albert.cabellos@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 0420D126CE8 for <lisp@ietfa.amsl.com>; Mon, 8 Jan 2018 15:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 PsRvSNp29hbO for <lisp@ietfa.amsl.com>; Mon, 8 Jan 2018 15:27:44 -0800 (PST)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 05A78126D05 for <lisp@ietf.org>; Mon, 8 Jan 2018 15:27:44 -0800 (PST)
Received: by mail-yb0-x22a.google.com with SMTP id v17so3790639ybl.10 for <lisp@ietf.org>; Mon, 08 Jan 2018 15:27:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C/JI+koUVAqaWotff8ESq3fupD5dikw+u1Y6alfGa7g=; b=YT5WfP41UrCWLCfUntUTqPGQATkpAxnTGKkPMWevEvxm2VFwNnsSydgRFPSGobp6cR etYLjJJQYoFlagg505R3PEavyt0hR9iGziE8cOOeFkcyg8NJ1Lv+C5FZocuzkjz/O8/7 BnsVwLVftMwT9+i3wMMVA5II5Zu1bS+DRofZr4aYIJDXekSxDaV3jsTIT4Alxwn0NqUU NFAmMOOZOyxqZsVpmQbsKFAByG6eWNci6QmjsDCCjl8UAxtUthLKOr0ASBi7xwC9N71p oagxJkXM2qc9Kp4RCgeJv+dwhprFseC7eHQ/AY/5TWf08SZmMSQlDG7LVMF7ynozzmKz qb9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C/JI+koUVAqaWotff8ESq3fupD5dikw+u1Y6alfGa7g=; b=EC9f0ifdE2AM586/DMN4B6ZlOrDQpnx2nYtwqUNU4qnvX72ycYEnUGFE2/imYzDH9U jSii+zrKQfbflOK30y6dIie6Dtk6YOul7OTTIg0fISGpU5LBKSOxzWqIjoP9FtVdyWVi GJex7UvQ4t/YYZeVQLgjgk3JTNCKdQI42DO+5xUVIGdrFABZ6wVgZJL25JCo6stLLuh9 Rc+UqOeeyzzYusmxEpbzW9OQQpb97OZfRmVNjexWqLJYlfJtyOIOP4MyLclIURFv7czC IwyGKRZq9DhVONeYTX922Ai3FX55yqOthMFbEn8s+JoXmKOBccXn4tJD1x1rgqu+0sl1 MCvg==
X-Gm-Message-State: AKGB3mLGX+VJd+fGPTrcnEVutj3Bvu3EJbqmB/uzX3ARI9d5PzyR5+ya VxP2lLoRGprymOCJdPFTmIwzPn5ssX4CilViePA=
X-Google-Smtp-Source: ACJfBosAnN6URDRqDi/qRSoivAEZX7b933SVoHabe85W6B8NIIw0Gkjq1TbggCidGyjfHDTfWRryff9rgV5ZOKQtOJ4=
X-Received: by 10.37.220.148 with SMTP id y142mr12572363ybe.468.1515454063148; Mon, 08 Jan 2018 15:27:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.164.38 with HTTP; Mon, 8 Jan 2018 15:27:42 -0800 (PST)
In-Reply-To: <DD4AAA1D-779C-444F-9C23-50CCA9935693@gmail.com>
References: <D5733FCE-0F37-45AE-BD5B-AA17953DD8EC@gmail.com> <52854B15-A8D8-47CA-8680-B2D673191EBA@gmail.com> <DD4AAA1D-779C-444F-9C23-50CCA9935693@gmail.com>
From: Albert Cabellos <albert.cabellos@gmail.com>
Date: Tue, 09 Jan 2018 00:27:42 +0100
Message-ID: <CAGE_Qeww-bFo122rc+XZQnQyzza0nC=BO2H+sg_FHz_Z+4dXEA@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Damien Saucez <damien.saucez@gmail.com>, LISP mailing list list <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c19181e1b84ef05624c253d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/tSj9gtHnt1BCzJv50K94NgX4gt4>
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 23:27:47 -0000

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? 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> 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>
> 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> 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
> >
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>