Subject: [lisp] Draft of new Proposed Charter

From: Luigi Iannone <[email-masked]>
Date: Tue, 13 Oct 2015 22:30:52 +0200

Folks,

in the past weeks (and months) there was a fruitful discussion that took place on the mailing list (and also in Prague) concerning 
the new charter to be adopted by our WG. Thanks for this effort.

Beside this discussion we had proposals from WG members as well as discussion with our AD about what is practical and reasonable.
Hereafter you can find the result: a draft of the new proposed charter.

This does not mean that discussion is over, rather that we reached a first consistent milestone for further discussion. 
Discussion ideally culminating in our meeting in Japan.

So please have look and send your thoughts and feedback to the mailing list.

Joel and Luigi

%—————————————————————————————————————————————————%
The LISP WG has completed the first set of Experimental RFCs
describing the Locator/ID Separation Protocol (LISP). LISP supports 
a routing architecture which decouples the routing locators and 
identifiers, thus allowing for efficient aggregation of the routing locator 
space and providing persistent identifiers in the identifier space. 
LISP requires no changes to end-systems or to routers that do not 
directly participate in the LISP deployment. LISP aims for an 
incrementally deployable protocol. The scope of the LISP
 technology is recognized to range from programmable overlays, 
at Layer 2 as well as at Layer 3, including NAT traversal, and 
supporting mobility as a general feature, independently of whether 
it is a mobile user or a migrating VM, hence being applicable in both
Data Centers and public Internet environments.

The LISP WG is chartered to continue work on the LISP base protocol 
with the main objective to develop a standard solution based on the 
completed Experimental RFCs and the experience gained from early 
deployments.
This work will include reviewing the existing set of Experimental RFCs 
and doing the necessary enhancements to support a base set of 
standards track RFCs. The group will review the current set of Working 
Group documents to identify potential standards-track documents and 
do the necessary enhancements to support standards-track. It is 
recognized that some of the work will continue on the experimental track, 
though the group is encouraged to move the documents to standards 
track in support of network use, whereas the work previously was 
scoped to research studies.

Beside this main focus, the LISP WG may work on the following items:

•	NAT-Traversal
•	Mobility
•	Data-Plane Encryption
•	Multicast: Support for overlay multicast by means of replication 
        as well as interfacing with existing underlay multicast support.
•	YANG Data models for management of LISP.
•	Multi-protocol support: Specifying the required extensions to support 
        multi-protocol encapsulation (e.g.,   L2 or NSH – Network Service 
        Headers). Rather than developing new encapsulations, the work will 
        aim at using existing well-established encapsulations or emerging 
        from other Working Groups such as  NVO3 and SFC.  
•	Alternative Mapping System Design: When extending LISP to support  
        new protocols,it may be also necessary to develop the related mapping 
        function extensions to operate LISP map-assisted  networks (which 
        might include Hierarchical Pull, Publish/Subscribe, or Push models 
        and related security extensions).

---

From: Fabio Maino <[email-masked]>
Date: Tue, 13 Oct 2015 14:53:25 -0700

Joel, Luigi,
thanks for taking a stab at this one.

I think it covers the relevant aspects that I would like to see the WG 
to focus on.

As discussed in the use case thread, I would suggest that the draft 
should mention a very small set of use cases that we can use to drive 
the design decisions. I think that we can possibly cover all of the 
protocol aspects you describe if we take the following two use cases:
1) LISP-based programmable L2/L3 VPNs with extensions to support the 
following services:
     - encryption
     - programmatic northbound access to the mapping and to xTR 
configuration
     - SFC/NFV
     - VPN termination on mobile nodes
2) LISP-based programmable L2/L3 VPNs for DC applications

I think these two will give a good scope to the WG work and, without 
resorting to more exotic use cases, reinforce the focus on the use of 
LISP as an overlay technology.

Thanks,
Fabio

On 10/13/15 1:30 PM, Luigi Iannone wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Albert Cabellos <[email-masked]>
Date: Wed, 14 Oct 2015 01:12:31 -0700

Hi Luigi, Joel

Thanks for the draft, I think it describes very relevant action items for LISP.

I would also suggest exploring a flexible data-modeling language as a
complement to LCAF for LISP control. LCAF is too rigid and it lacks of
design guidelines to define new ones. A flexible language with a clear
syntax would ease deployment of new use-cases both at the data and
control plane. Maybe this could be done as experimental (not
standard).

Albert

On Tue, Oct 13, 2015 at 2:53 PM, Fabio Maino <[email-masked]> wrote:
> I think it covers the relevant aspects that I would like to see the WG to focus on.
>
> As discussed in the use case thread, I would suggest that the draft should mention a very small set of use cases that we can use to drive the design decisions. I think that we can possibly cover all of the protocol aspects you describe if we take the following two use cases:
> 1) LISP-based programmable L2/L3 VPNs with extensions to support the following services:
>     - encryption
>     - programmatic northbound access to the mapping and to xTR configuration
>     - SFC/NFV
> I think these two will give a good scope to the WG work and, without resorting to more exotic use cases, reinforce the focus on the use of LISP as an overlay technology.
>
> Thanks,
> Fabio
>
>
>
>

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 14 Oct 2015 10:23:15 +0200

Hi Fabio,

thanks for the feedback.
Are you saying that the scope of the proposed chart is too large?

From what I see in your mail I would say that the proposed charter covers all of your work items (with the exception of the programmatic northbound access to the mapping).

Or I am misunderstanding your comment?

ciao

L.

> On 13 Oct 2015, at 23:53, Fabio Maino <[email-masked]> wrote:
> 
> Joel, Luigi,

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 14 Oct 2015 10:31:49 +0200

HI Albert,

thanks for the feedback.

> On 14 Oct 2015, at 10:12, Albert Cabellos <[email-masked]> wrote:
> 
> Hi Luigi, Joel
> 

:-)

> design guidelines

Having design guidelines does not forcedly mean having a programmatic language approach. Right?

In your opinion  could well defined guidelines (not language) be added to the current LCAF document? 

> to define new ones. A flexible language with a clear
> control plane.

How much relevant and with what priority is this for the WG? ( _NOTE_ this question is for the whole WG not just for Albert…)

> Maybe this could be done as experimental (not
> standard).

_if_ the WG decides to take on this work it would very reasonable to go for experimental.

ciao

L.

---

From: Fabio Maino <[email-masked]>
Date: Wed, 14 Oct 2015 08:27:04 -0700

> Are you saying that the scope of the proposed chart is too large?

No, I think the scope is very appropriate. I was just suggesting that we 
use those two use cases to drive the design decisions.

There are clearly many more use cases that a LISP overlay can be used 
for, but in my opinion those two are well understood and will help 
focusing the group on the protocol work that you have identified. I 
selected those two, and articulated them in that way, exactly because 
they can cover the whole scope of the outlined work.

If we include those two use cases in the charter, probably it should 
also mention that those are not the only ones, but are used to drive the 
design.

>  From what I see in your mail I would say that the proposed charter covers all of your work items (with the exception of the programmatic northbound access to the mapping).

Yes. I think the SDN angle is very important for an overlay, and may 
drive very relevant components of the architecture. The text you posted 
does refers to YANG modeling, that is one component of programmability, 
but I would like to see this requirement more explicit, particularly for 
the mapping system.

I believe LISP, with the clean separation of the forwarding function 
provided by the mapping system, can play a key role in controller-based 
SDN applications. Again, it's not the only way to use LISP, but I think 
it's an opportunity that the WG should pick up.

Thanks,
Fabio

---

From: Sharon <[email-masked]>
Date: Wed, 14 Oct 2015 11:28:54 -0700

We could say that as we completed a set of experimental lisp rfcs the importance of connectionless logical services networks overlaying and or anchoring topological IP networks grew significantly. 

To accommodate we continue to evolve the unique lisp map-assisted overlay architecture characteristics along the following lines:
- traversal, schemas, chaining... etc

We evolve these lisp aspects and examine their applicability by matching and testing them vis-a-vis key example use-cases:
- VPN virtual logical private services networks
- NFV virtualization of functions from junctions 
- DMM distributed (floating-anchors) mobility  

--szb

> On Oct 14, 2015, at 8:27 AM, Fabio Maino <[email-masked]> wrote:
> 
> No, I think the scope is very appropriate. I was just suggesting that we use those two use cases to drive the design decisions.
> 
> There are clearly many more use cases that a LISP overlay can be used for, but in my opinion those two are well understood and will help focusing the group on the protocol work that you have identified. I selected those two, and articulated them in that way, exactly because they can cover the whole scope of the outlined work.
> 
> If we include those two use cases in the charter, probably it should also mention that those are not the only ones, but are used to drive the design.
> 
>> 
> Yes. I think the SDN angle is very important for an overlay, and may drive very relevant components of the architecture. The text you posted does refers to YANG modeling, that is one component of programmability, but I would like to see this requirement more explicit, particularly for the mapping system.
> 
> I believe LISP, with the clean separation of the forwarding function provided by the mapping system, can play a key role in controller-based SDN applications. Again, it's not the only way to use LISP, but I think it's an opportunity that the WG should pick up.
> 
> 
> 
> Thanks,
> Fabio
> 
> 
>

---

From: Albert Cabellos <[email-masked]>
Date: Wed, 14 Oct 2015 15:10:52 -0700

Hi Luigi

Please see my comments inline:

On Wed, Oct 14, 2015 at 1:31 AM, Luigi Iannone <[email-masked]> wrote:

[snip]

> In your opinion  could well defined guidelines (not language) be added to the current LCAF document?

I am unsure if we can do this without ending up reproducing some sort
of language, we´ll start by defining scalar data-types, then complex
data-types (combinations of scalars), then data-structures, then
encoding mechanisms for each scalar and each data-structure and so on.

This could be as simple as defining an encoding mechanisms for YANG
(XMLBIN with some sort of compression). I am not stating that we
should go this precise way, what I am stating is that LCAF is rigid
and, if a new use-case is not defined as an LCAF, it can´t be deployed
in a standard way. A language could solve this issue and make the LISP
control plane truly flexible.

> How much relevant and with what priority is this for the WG? ( _NOTE_ this question is for the whole WG not just for Albert…)

me too :)

Albert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Oct 2015 19:04:14 -0400

I am really unclear as to what the problem being addressed by creating a 
programmatic language for LCAFs is.  Heck, I am confused by what the 
JSON LCAFs are solving too.

Beyond that, I do not even know what it means to support such LCAF 
through a mapping system.

It sounds a lot like research, rather than engineering.  But I that may 
be just because I have completely missed the point.

Yours,
Joel

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 15 Oct 2015 11:41:43 +0200

Hi Fabio,

> On 14 Oct 2015, at 17:27, Fabio Maino <[email-masked]> wrote:
> 

I kind of confused here. You agree that there is the right scope in the proposed charter but that is lacking use-cases. 

I would prefer having a charter that states what we are working on, not where our work can/will be applied.

If people are interested in use-cases, it is possible to add a use-case document where we document where the work can be used.

Would people be happy with such type of solution?

> I believe LISP, with the clean separation of the forwarding function provided by the mapping system, can play a key role in controller-based SDN applications. Again, it's not the only way to use LI…

I would prefer that in the charter we refer only to IETF work. This means avoiding acronyms like SDN. First because it is a I_R_TF work, second because SDN way too large. It means different things for different people, so I am unsure on whether it helps in defining a clear scope for our work.
YANG is different, because it is clearly an IETF effort and is something that we have anyway to consider.

Yet, you can always propose some text to help in give a better scope to the proposed charter.

ciao

L.

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 15 Oct 2015 11:47:31 +0200

Hi Albert

I may agree with you in what can be done and what is interesting, but…..

At this point it looks to me (personal opinion) as a bit premature to add such kind of working item.
It looks like we are still at very early stage where we still look what kind of solution would be the best fit.

Or have you more precise ideas?

ciao

L.

> On 15 Oct 2015, at 00:10, Albert Cabellos <[email-masked]> wrote:
> 
> Hi Luigi
>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 15 Oct 2015 11:52:43 +0200

Hi Sharon,

> On 14 Oct 2015, at 20:28, Sharon <[email-masked]> wrote:
> 
> - traversal, schemas, chaining…

Thanks the above observation can be converted to text for the new charter. Let me think a bit the way to do it.
> etc

> - DMM distributed (floating-anchors) mobility  

References to VPN and DMM can be added, since this is IETF work.

For NFV, is I have the same comment as for SDN. It looks to me that in this way we make scope more fuzzy rather than clear. Moreover, like for SDN, this is IRTF work.

ciao

L.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Oct 2015 12:08:30 -0400

Agreed.  My concerns in the LCAF aspects revolve around EID usage.  RLOC 
usage is, as you say, understandable.

Yours,
joel

On 10/15/15 11:26 AM, Dino Farinacci wrote:
>> I am really unclear as to what the problem being addressed by creating a programmatic language for LCAFs is.  Heck, I am confused by what the JSON LCAFs are solving too.
>
> At this point in time, it is not clear to me how the JSON LCAF would be used as an EID-record. However, returning a JSON dictionary array as output of a lookup (an RLOC-record), is quite useful. Doing that latter requires no mapping system changes. Doing the former would require a major change IMO.
>
> Dino
>