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
