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 protected]> 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 <[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
