Re: [lisp] Way forward on 6830bis

[Albert Cabellos <[e-mail]>]

+1 to this

Albert

On Thu, Nov 5, 2015 at 11:12 PM, Florin Coras <[e-mail]> 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 <[e-mail]> wrote:
>>
>> I certainly agree with your conclusions Fabio.
>>
>> Dino
>>
>>> On Nov 4, 2015, at 6:13 PM, Fabio Maino <[e-mail]> wrote:
>>>
>>> On 11/5/15 11:06 AM, Damien Saucez wrote:
>>>> On 05 Nov 2015, at 10:48, Dino Farinacci <[e-mail]> wrote:
>>>>
>>>>> On 05 Nov 2015, at 10:33, Dino Farinacci <[e-mail]> 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 <[e-mail]> 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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>>> _______________________________________________
>>>>>>>> lisp mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>> _______________________________________________
>>>> lisp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp