Subject: [lisp] Update Proposed CHarter

From: Luigi Iannone <[email-masked]>
Date: Mon, 4 Jan 2016 13:44:41 +0100

Hi and Happy 2016 to All,

time to restart our WG activity in this new year. ;-)

We tried to include all comments received via mail and stated during the last meeting in Japan into an updated charter.
Changes are relatively minor, showing that the WG has almost converged to a proposal.
Yet, before pushing the new charter to the IESG for approval, we would like to have a last short iteration in the WG.
Hereafter you can find the updated text. 

If the text looks good for you, please state so in the mailing list.

If you think something is missing or can be improved, please state so in the mailing list.

Thanks 

Joel and Luigi

%%%%%%%% Updated Proposed Charter %%%%%%%%%%%%%%%%%%%%%%%%

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 techology is recognized to range 
from unicast and multicast overlays at Layer 2 as well 
as at Layer 3, including NAT traversal, VPNs, and 
supporting mobility as a general feature, independently 
of wheter 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 experimental
documents.

Beside this main focus, the LISP WG 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.

-       Models for managing the LISP protocol and deployments
        that include data models, as well as allowing for
        programmable management interfaces. These managament
        methods should be considered for both the data-plane,
        control-plane, and mapping system components

-       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 Grops such as  NVO3 and SFC.

-       Alternative Mapping System Design. By extenting LISP
        with  new protocols support it is also necessary to
        develop the required mapping function extensions to
        operate LISP map-assisted  networks (which might
        include Hierarchical Pull, Publish/Subscribe, or Push
        models and related security extension).

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Jan 2016 11:49:14 -0800

> If the text looks good for you, please state so in the mailing list.

I am fine with the text. But I have one comment about sequencing the list below. Can we sequence the list in order of generality or importance?

See inline comment below.

>        models and related security extension).

I will number the above as 1 - 7 and feel they should be ordered in sequence:

6, 7, 2, 4, 3, 1, 5

Dino

---

From: Sharon <[email-masked]>
Date: Mon, 4 Jan 2016 14:42:34 -0800

I agree with Dino, will pull up (1) though, it allows carriers to anchor access services in POPs where the MAO operations are based.
Cloud RAN, NFV, VPN .. type services.

--szb

On Jan 4, 2016, at 11:49 AM, Dino Farinacci <[email-masked]> wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Jan 2016 18:09:54 -0500

And this is why I tend to prefer an un-ordered list.  But if the WG 
wants to try to agree on a prioritized list, go for it.

Yours,
Joel

---

From: Fabio Maino <[email-masked]>
Date: Mon, 4 Jan 2016 15:30:01 -0800

Hi Luigi,
it looks good to me.

One item that was mentioned at the last meeting was to include the work 
done so far on map server reliable transport.

One possible way to include it is to change the very last bullet to 
something like:

- Alternative Mapping System Design. By extending LISP with  new 
protocols support it is also necessary to develop the required mapping 
function extensions to operate LISP map-assisted  networks (which might 
include Hierarchical Pull, Publish/Subscribe, or Push models and related 
security extensions, *or alternative transports of the LISP control 
protocol*).

Thanks,
Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Jan 2016 15:48:53 -0800

I should have NOT said in “order of importance”. It is in order of more general to specific features. They are all important and a bullet at the end is not any less important or less priority than prior bullets.

Dino

> On Jan 4, 2016, at 3:09 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> And this is why I tend to prefer an un-ordered list.  But if the WG wants to try to agree on a prioritized list, go for it.
> 
> Yours,
> Joel
>

---

From: "Vina Ermagan (vermagan)" <[email-masked]>
Date: Tue, 5 Jan 2016 01:49:04 +0000

Hello Chairs,

Thanks for the text. One minor comment: in addition to Fabio's suggestion,
perhaps we can also include a wording that explicitly includes control
plane protocol extensions needed to accommodate the new mapping functions.
I have captures both additions in << >> below.

- Alternative Mapping System Design. By extending LISP with  new protocols
support it is also necessary to develop the required mapping function <<
and control plane >> extensions to operate LISP map-assisted  networks
(which might include Hierarchical Pull, Publish/Subscribe, or Push models
and related security extensions, << or alternative transports of the LISP
control protocol >>).

Regarding the ordering of the list, I believe we should stay away from
officially prioritizing the list in the charter. Therefore I think we
should avoid numbering the list. I have no objection to re-arranging the
list in any order as long as it does not imply prioritization.

Best,
Vina

On 1/4/16 3:09 PM, "Joel M. Halpern" <[email-masked]> wrote:

>> I agree with Dino, will pull up (1) though, it allows carriers to
>>anchor access services in POPs where the MAO operations are based.
>>> I am fine with the text. But I have one comment about sequencing the
>>>list below. Can we sequence the list in order of generality or
>>>importance?
>>>
>>>>        (e.g.,   L2 or NSH  Network Service Headers). Rather

---

From: Damien Saucez <[email-masked]>
Date: Tue, 5 Jan 2016 23:39:24 +0100

Dear chairs,

I support the new chartes with the changes proposed by Fabio and Vina.

As Joel and Vina, I would prefer not to order the different points as such
prioritisation would be highly subjective.

Cheers,

Damien Saucez

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 6 Jan 2016 15:21:30 +0100

HI All,

We can certainly re-order the bullets following Dino’s suggestion. 
I would not put any text about priority and/or importance, just because any person working on a specific bullet will obviously think that his/her work is the most important. ;-)

Does it sound OK for the WG?

Ciao

L.

> On 05 Jan 2016, at 23:39, Damien Saucez <[email-masked]> wrote:
> 
> Dear chairs,
>

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 6 Jan 2016 15:27:13 +0100

Thanks Vina, Fabio,

I do not see any objection in adding the suggested text.

Ciao

L.

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 6 Jan 2016 15:42:27 +0100

Hi All,

Hereafter a new version of the charter with the comments received so far.

Please send more feedback. Would be good if we can send the charter to our AD by next week.

ciao

L.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

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 techology is recognized to range from unicast and multicast overlays at Layer 2 as well as at Layer 3, including NAT traversal, VPNs,  and supporting mobility as a general feature, independently of wheter 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 experimental documents.

·       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 Grops such as  NVO3 and SFC.  

·       Alternative Mapping System Design. By extenting LISP with  new protocols support it is also necessary to develop the required mapping function and control plane extensions to operate LISP map-assisted  networks (which might include Hierarchical Pull, Publish/Subscribe, or Push models, independednt mapping systems interconnection, security extensions, or alternative transports of the LISP control protocol).

·       Mobility

·       Multicast: Support for overlay multicast by means of replication as well as interfacing with existing underlay multicast support.

·       Data-Plane Encryption

·       NAT-Traversal

·       Models for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These managament methods should be considered for both the data-plane, control-plane, and mapping system components.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Jan 2016 12:44:02 -0800

This version looks good to me.

Dino

> On Jan 6, 2016, at 6:42 AM, Luigi Iannone <[email-masked]> wrote:
> 
> Hi All,
>

---

From: "Vina Ermagan (vermagan)" <[email-masked]>
Date: Wed, 6 Jan 2016 20:46:13 +0000

Thanks Luigi, this version looks great.

Best,
Vina

On 1/6/16 6:42 AM, "Luigi Iannone" <[email-masked]> wrote:

>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 techology is recognized to range from
>unicast and multicast overlays at Layer 2 as well as at Layer 3,
>including NAT traversal, VPNs,  and supporting mobility as a general
>feature, independently of wheter 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 experimental
>documents.
>
>·       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 Grops such as  NVO3 and SFC.
>
>·       Alternative Mapping System Design. By extenting LISP with  new
>function and control plane extensions to operate LISP map-assisted
>networks (which might include Hierarchical Pull, Publish/Subscribe, or
>Push models, independednt mapping systems interconnection, security
>extensions, or alternative transports of the LISP control protocol).
>
>·       Mobility
>
>·       Multicast: Support for overlay multicast by means of replication
>as well as interfacing with existing underlay multicast support.
>
>·       Data-Plane Encryption
>
>·       NAT-Traversal
>
>·       Models for managing the LISP protocol and deployments that
>include data models, as well as allowing for programmable management
>interfaces. These managament methods should be considered for both the
>data-plane, control-plane, and mapping system components.
>
> 
>

---

From: Fabio Maino <[email-masked]>
Date: Wed, 6 Jan 2016 13:39:48 -0800

Looks good Luigi.

Thanks,
Fabio

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Sat, 9 Jan 2016 22:04:52 +0000

Luigi,

Where would enhancements of the protocol - like Reliable Transport - fit into the below text?  I’d like to make sure that things like this and a pub/sub distribution model are explicitly mentioned, because they are actively being developed by multiple implementers - maybe ‘alternative Mapping System Design’ is too narrow a focus?

-Darrel

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 11 Jan 2016 15:00:39 +0100

Hi Darrel,

I am not sure I follow your comment. 
Both Pub/Sub and reliable transport are mentioned in the proposed draft.

Can you elaborate a bit what  in your opinion is missing?

Ciao

L.

> On 09 Jan 2016, at 23:04, Darrel Lewis (darlewis) <[email-masked]> wrote:
> 
> Luigi,
>