Hi Albert,
> On 9 Jan 2018, at 00:27, Albert Cabellos <[email protected]> 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. > > I would like to hear other opinions from the list > > Albert > > On Mon, Jan 8, 2018 at 7:22 PM, Dino Farinacci <[email protected] > <mailto:[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] > > <mailto:[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] > >> <mailto:[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] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/lisp > >> <https://www.ietf.org/mailman/listinfo/lisp> > > > > _______________________________________________ > lisp mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lisp > <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
