+1 to this Albert
On Thu, Nov 5, 2015 at 11:12 PM, Florin Coras <[email protected]> wrote: > Definitely agree with this as well. > > As Damien mentioned, RFC6830 convolutes control-plane API definition and > semantics with data-plane operation. While I believe there should be a > section treating tunnel router interaction with the mapping-system in > RFC6830, the control-plane API definition (i.e., syntax and semantic of > messages exchanged by tunnel routers with the mapping-system), should be > moved to a separate document. > > Florin > >> On Nov 5, 2015, at 3:42 AM, Dino Farinacci <[email protected]> wrote: >> >> I certainly agree with your conclusions Fabio. >> >> Dino >> >>> On Nov 4, 2015, at 6:13 PM, Fabio Maino <[email protected]> wrote: >>> >>> On 11/5/15 11:06 AM, Damien Saucez 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, >>> I think this could be a good idea. Too many people still associate LISP >>> mostly with the encap (and it looks like too many don't read past the title >>> of the RFC... :-( >>> >>> We should also do a better work of explaining that LISP CP can be used as >>> generic mapping service for overlays (not only for on-demand LISP tunnel >>> provisioning). >>> >>> In retrospective we should have presented the LISP/NSH draft in SFC as >>> well.There might be more SFC use cases that can be addressed by the LISP >>> CP. It'd be helpful to have the people in SFC give a thought to the concept >>> of map assisted overlays. >>> >>> Fabio >>> >>> >>>> >>>> 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 >> >> _______________________________________________ >> 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
