Subject: Re: [lisp] Way forward on 6830bis

From: Damien Saucez <[email-masked]>
Date: Thu, 5 Nov 2015 10:29:38 +0900

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.

Cheers,

Damien Saucez 

On 27 Oct 2015, at 01:25, Joel M. Halpern <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Nov 2015 17:33:24 -0800

> not requiring people to care about the LISP encapsulation if they only need the

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.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Thu, 5 Nov 2015 10:39:46 +0900

> 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…

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? 

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Nov 2015 17:48:18 -0800

> 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.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Thu, 5 Nov 2015 11:06:44 +0900

> 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 o…

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

---

From: Fabio Maino <[email-masked]>
Date: Thu, 5 Nov 2015 11:13:54 +0900

> 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

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Thu, 5 Nov 2015 03:28:30 +0100

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-masked]>
wrote:

> >>> 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.
> >>>
> >>
> > 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.
> >
>
>
> >>>>> 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
> >>>>>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Nov 2015 18:41:55 -0800

> “encapsulation”.

If the new charter allows to incorporate additional data-planes, then RFC6830bis could be structured to (1) indicate that multiple data-planes can be used and (2) how more we can decouple the data-plane from the control-plane.

> would allow both planes to be developed (and updated) in parallel.

There are pros and cons either way.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Nov 2015 18:42:56 -0800

I certainly agree with your conclusions Fabio.

Dino

> On Nov 4, 2015, at 6:13 PM, Fabio Maino <[email-masked]> wrote:
> 
> 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
>>>>>>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Nov 2015 18:43:51 -0800

> 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”.

Agree as well.

Dino

---

From: Florin Coras <[email-masked]>
Date: Thu, 5 Nov 2015 15:12:20 +0100

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-masked]> wrote:
>

---

From: Albert Cabellos <[email-masked]>
Date: Fri, 6 Nov 2015 09:40:47 +0900

+1 to this

Albert