[Int-area] FW: LISP, San Francisco, and WG

[Jari Arkko <[e-mail]>]

Since some of the discussion was on this forum earlier, I'm sending this 
as a FYI here as well. Please continue the discussion on the LISP 
mailing list (https://www.ietf.org/mailman/listinfo/lisp).

Jari

Jari Arkko wrote:
> All,
>
> After considering the input from the various lists, IESG, IAB, etc, I 
> have decided that the best course of action with regards to LISP is to 
> create a tightly scoped WG. The scoping relates to truth in 
> advertising about the readiness of the technology for wide deployment 
> and how the results of the WG will be used. The specifications coming 
> out of the WG will be Experimental RFCs. Please see the charter text 
> below; comments appreciated. And I see that we've already received 
> feedback from Margaret, thanks for that.
>
> The group is expected to work on one specific solution, converting 
> that solution to something else is not within the plan. The RRG 
> obviously needs to continue their work with a number of other 
> solutions and analysis of the design space. I plan to keep the door 
> open for other proposals as well (some could argue that 6AI is another 
> solution; that might become a WG too in San Francisco). I don't think 
> anyone believes that either LISP or the other solutions from RRG are 
> ready for prime time; there are significant remaining problems even at 
> the conceptual and incentive levels, let alone protocol bits. But 
> before we get to a final solution, it is very useful to test various 
> designs, to understand their implications.
>
> A formal call for IETF-wide comments on the proposed working group and 
> charter will be made in the next few days. You can send input on this 
> list or say something at the meeting. The final approval will happen 
> after San Francisco. At the end of the day we will decide this based 
> on the community feedback, but my expectation is that there is support 
> for letting the LISP folks work on their design in the IETF.
>
> Sam Hartman and Darrel Lewis have agreed to chair the group -- thank 
> you! Please talk to the chairs about agenda; we are obviously doing 
> this quite late before the meeting, so a lot of preparation has to 
> happen in a short amount of time. Other than the opportunity for 
> feedback on the WG creation and the charter, I think we should run the 
> meeting as if it were a WG meeting.
>
> Jari
>
> --------
>
> LISP (Locator/ID Separation Protocol)
>
> Last Modified: 2009-03-12 21:01:40
>
> Chair(s):
> TBD
>
> Internet Area Director(s):
> TBD
>
> Routing Area Advisor:
> TBD
>
> Mailing Lists:
> General Discussion: https://www.ietf.org/mailman/listinfo/lisp
>
> Description of Working Group:
>
> The IAB's October 2006 workshop on Routing and Addressing Workshop
> (RFC 4984) rekindled interest in scalable routing and addressing
> architectures for the Internet. Among the many issues driving this
> renewed interest are concerns about the scalability of the routing
> system and the impending exhaustion of the IPv4 address space. Since
> the IAB workshop, several proposals have emerged which attempt to
> address the concerns expressed there and elsewhere. In general, these
> proposals are based on the "Locator/Identifier separation".
>
> The basic idea behind the separation that the Internet architecture
> combines two functions, Routing Locators, or RLOCs (where you are
> attached to the network) and Endpoint Identifiers, or EIDs (who you
> are) in one number space: The IP address. Proponents of the separation
> architecture postulate that splitting these functions apart will yield
> several advantages, including improved scalability for the routing
> system. The separation aims to decouple location and identity, thus
> allowing for efficient aggregation of the RLOC space and providing
> persistent identity in the EID space.
>
> LISP supports the separation of the Internet address space into
> Endpoint Identifiers and Routing Locators following a
> network-based map-and-encap scheme (RFC 1955). It employs
> EIDs that represent a mixture of locators and identifiers; it
> could also be classified as a multi-level locator scheme.
> A number of other approaches are being looked at in parallel in
> the IRTF and IETF.  At this time, these proposals are at
> an early stage.  All proposals (including LISP) have potentially
> harmful side-effects to Internet traffic carried by the involved
> routers, have parts where deployment incentives may be lacking, and
> are NOT RECOMMENDED for deployment beyond experimental
> situations at this stage. Many of the proposals have components (such
> as the EID-to-RLOC mapping system) where it is not yet known what kind
> of design alternative is the best one among many.
>
> However, despite these issues it would be valuable to write
> concrete protocol specifications and develop implementations that can
> be used to understand the characteristics of these designs. The LISP
> WG is chartered to work on the LISP base protocol
> (draft-farinacci-lisp-12.txt),  the LISP+ALT mapping system
> (draft-fuller-lisp-alt-05.txt), LISP Interworking
> (draft-lewis-lisp-interworking-02.txt), LISP Map Server
> (draft-fuller-lisp-ms-00.txt), and LISP multicast
> (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the 
> given
> drafts as a starting point. The working group will encourage and
> support interoperable LISP implementations as well as defining
> requirements for alternate mapping systems. The Working Group
> will also develop security profiles for the ALT and/or other mapping
> systems.
>
> It is expected that the results of specifying, implementing, and
> testing LISP will be fed to the general efforts at the IETF and IRTF
> (e.g., the Routing Research Group) that attempts to understand which
> type of a solution is optimal. The LISP WG is NOT chartered to develop
> the final or standard solution for solving the routing scalability
> problem. Its specifications are Experimental and labeled with accurate
> disclaimers about their limitations and not fully understood
> implications for Internet traffic. In addition, as these issues are
> understood, the working group will analyze and document the
> implications of LISP on Internet traffic, applications, routers, and
> security. This analysis will explain what role LISP can play in scalable
> routing. The analysis should also look at scalability and levels of state
> required for encapsulation, decapsulation, liveness, and so on
> (draft-meyer-loc-id-implications).
>
> Goals and Milestones:
>
> Mar 2010  Submit base LISP specification to the IESG as Experimental
>
> Mar 2010  Submit base ALT specification to the IESG as Experimental
>
> Mar 2010  Submit the LISP Interworking specification to the IESG as
> Experimental
>
> June 2010 Submit the LISP Map Server specification to the IESG as
> Experimental
>
> June 2010 Submit Recommendations for Securing the LISP Mapping System to
> the IESG as Experimental
>
> Jul 2010  Submit LISP for Multicast Environments to the IESG as
> Experimental
>
> Dec 2010  Submit a preliminary analysis as Informational
>
> Dec 2010  Re-charter or close.
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>
>