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

Dino Farinacci <> Mon, 08 January 2018 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68BDE127876 for <>; Mon, 8 Jan 2018 10:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MYjimhGkMQoj for <>; Mon, 8 Jan 2018 10:22:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCA6312D7F7 for <>; Mon, 8 Jan 2018 10:22:59 -0800 (PST)
Received: by with SMTP id e3so6534958pfi.10 for <>; Mon, 08 Jan 2018 10:22:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kzQ2dlilJsTvoPgZYQ+oFvepud48/umKQG1wE3bPprE=; b=Ng7/gb36g2Ss2feyVB8yBqV3pVUdaWT+59YmtZpznQA7gJLd0aYBTpwHEzOIfe++fV PIjKIT7+zSG3yVAgqcv0AIZvYgPioHtJsWJb+YPZIQWrnmk9CWF27vONxP2WCkYgCUwn dqEqg3+jgSDCigAx3Vl7RBk8ZR5Rr/jxYgwIsH14hb2ijiUvqf0AgFMp4ivJhPEwfpRp RnuZzmo04tB0ipdu4eUVJXcveS3wcXoBvEXE4rvv+Bt/Tn1t3cX16K31FNYUFbluxpK8 KB+8/xR/Hy3NRmjbZmZnMtPOMONJw1leSw7OTMUnyaW3PkmwWI6mIIxjcrizsoKQvke2 yHGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kzQ2dlilJsTvoPgZYQ+oFvepud48/umKQG1wE3bPprE=; b=YXe0Ym/TkH3tM1i80qBnsgvaJuHDRGlb8z16GcVsaV7Lr0HD6EeFOVplBIs5g+U2pd AxaSy1wk1KJjsNbuY5zqhNJLBpBh2/E3EulZB4Hb5H7ipYle6kwMWx+Qe96DA4vS7bfT zJZ3lRyDcHs5sxDf3v8lLyALCKmmP0xuBrXK7xdX9X/jLhXBJhAAIDAWkG3EvxTy1yNJ +tFUsL4GXCBZ6n3zFV5+e0JpNgMrc/YlRphyNSm/PscjDvIocWBphKA/60NcQlw43+zC KzIjuFKxJ9bsMYki1PncWUDKwsDWxG5gKLq4R3pPQo5wFX6aZpfRkdmG0/GcaMJP/0Am 9T7g==
X-Gm-Message-State: AKGB3mLBFD3POXyfC60e0JtQYR13sQ0R5cDZLju9AylvOsWpNGjUbGEN nayV/g/Ofimh1pqa23gv+mE=
X-Google-Smtp-Source: ACJfBou1BgqmfWgc7XcTIN1RncZ+6DBCt+w0FWbTmKLop+6bT8+OTk7Z1wXiFlUNDWqD8Y/IrIu16A==
X-Received: by with SMTP id c12mr10471677pgq.105.1515435779378; Mon, 08 Jan 2018 10:22:59 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e8sm28949902pfk.6.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jan 2018 10:22:58 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Mon, 08 Jan 2018 10:22:57 -0800
Cc: LISP mailing list list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Damien Saucez <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [lisp] Current changes for draft-ietf-lisp-rfc6830bis-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jan 2018 18:23:02 -0000

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.


> On Jan 8, 2018, at 9:16 AM, Damien Saucez <> 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 <> 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