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 protected]> wrote: > > 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: >> 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). >> >> _______________________________________________ >> 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
