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
