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
