Adding to the discussion here, I have to said that Damien raised a very valid point. In my understanding RFC6830 is covering aspects both of control and data. I also agree that for me control-plane is something more than just RFC6833 and that there are aspects of it covered in RFC6830 and in other documents.
I'm in favour of trying to avoid too much semantics discussion about what is what. Rather I think that be should think of it in a more pragmatic way. At the end of the day what we care is what we can do with the protocol, and what we want to do now is to be able to use the LISP control-plane standalone without being tied to the LISP data-plane. In that sense I think that we should ask ourselves the question, if I'm willing to use (for instance) VXLAN-GPE for encapsulation and LISP for the control-plane, which pieces of what is currently covered in RFC6830, RFC6833, etc, do I need to use? That is what for me should go into the "control-plane" document. The rest of the pieces of the LISP protocol that I didn't use since I had VXLAN-GPE, would be the "data-plane". Just my 2 cents here. Alberto On Thu, Nov 5, 2015 at 3:06 AM, Damien Saucez <[email protected]> wrote: > > On 05 Nov 2015, at 10:48, Dino Farinacci <[email protected]> wrote: > > > On 05 Nov 2015, at 10:33, Dino Farinacci <[email protected]> wrote: > >> > >>>> Hello, > >>>> > >>>> By seeing Alberts presentation on SFC today I was just thinking that > we could > >>>> split 6830 in two documents. > >>>> > >>>> One document to present the data-plane (mostly Sec 5). > >>>> > >>>> One document to present the control-plane (mostly Sec 6). > >>>> > >>>> As Albert said the mapping system is generic (with LCAF). Therefore > it would > >>>> make it more logical (to me at least) to have a document to strictly > talk about > >>>> the mapping system and it would increase the appeal of the mapping > system by > >>>> not requiring people to care about the LISP encapsulation if they > only need the > >>>> mapping system function. > >>> > >>> The mapping system is in a separate document and spread across alt, > ddt, and ms specs. The control-plane text in RFC6830 is defining an API to > the mapping system. And I think you want it all in one place for > completeness. > >>> > >> > >> When I was talking about mapping system, I was talking about the > >> “API” (Map-Request, Map-Reply, Map-Register… ). > >> > >> I understand that it is not straightforward to make it in a nice way, > but > >> the as LISP is about decoupling control-plane and data-plane it would > >> make sense to also decouple control and data-plane definition. > >> > >> Imagine you want someone to only implement the control-plane, how > >> does he know what to implement exactly to be fully compliant? > > > > This is clearly stated in RFC6830. That is, you can send a Map-Request > for any reason. It doesn’t have to be invoked by arrival of a packet on an > ITR/RTR/PITR. Tools like lig and rig are examples of this. > > > > > Of course for someone who knows LISP it is trivial that it is separated. > The > issue is how to move forward and ensure that LISP control plane is not > bound at > all to a particular data-plane. Actually, since the beginning we say LISP > is > map-and-encap so it means two components mapping and encapsulation, that > seems > thus very logical to me to have to documents, one for "mapping", one for > “encapsulation". > > At a first glance it could look like just being marketing but actually > splitting > would allow both planes to be developed (and updated) in parallel. > > Damien Saucez > > > Dino > > > >> > >> Damien Saucez > >> > >>> Dino > >>> > >>>> > >>>> Cheers, > >>>> > >>>> Damien Saucez > >>>> > >>>> On 27 Oct 2015, at 01:25, Joel M. Halpern <[email protected]> > wrote: > >>>> > >>>>> It seemed to us that there was likely some confusiona bout how we > expect to handle the revision of RCC 6830. The following is what we > currently expect. > >>>>> > >>>>> Once we have a new charter approved, the chairs will appoint an > editor for the revision of rfc6830. That may be one of the existing > authors, or a new person. We will ask for volunteers. > >>>>> > >>>>> Once we have an author, they will submit a starting ID called > draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the > existing RFC. That may require assistance from the RFC Editor to ensure > that we get all the changes they made during final edit. > >>>>> > >>>>> At that point, we will use the trouble ticket system to record > issues that people bring up. We will also discuss on the list what changes > we wish to make according to the charter. Things will tehn proceed in the > usual fashion, using the trouble ticket system to help make sure we do not > drop any of the issues. > >>>>> > >>>>> Yours, > >>>>> Joel & Luigi > >>>>> > >>>>> _______________________________________________ > >>>>> 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 >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
