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