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

From: Dino Farinacci <[email-masked]>
Date: Thu, 4 Jan 2018 09:00:30 -0800

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

---

From: Damien Saucez <[email-masked]>
Date: Mon, 8 Jan 2018 18:16:08 +0100

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 <[email-masked]> wrote:
> 
> <rfcdiff-rfc6830bis.html>_______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Jan 2018 10:22:57 -0800

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 <[email-masked]> wrote:
> 
> Hello Dino, The List,
>

---

From: Albert Cabellos <[email-masked]>
Date: Tue, 9 Jan 2018 00:27:42 +0100

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 <[email-masked]> 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
>
> >> 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
> >>
> _______________________________________________
> lisp mailing list
> [email-masked]

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 9 Jan 2018 16:06:58 +0100

Hi Albert,

> On 9 Jan 2018, at 00:27, Albert Cabellos <[email-masked]> 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.
> 
> On Mon, Jan 8, 2018 at 7:22 PM, Dino Farinacci <[email-masked] <mailto:[email-masked]>> wrote:
> > On Jan 8, 2018, at 9:16 AM, Damien Saucez <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hello Dino, The List,
> >
> >> On 4 Jan 2018, at 18:00, Dino Farinacci <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>
> >
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>
>