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