Re: [lisp] LISP: update to charter in external review

[Michael Menth <[e-mail]>]

Hi Sam,

Sam Hartman schrieb:
> I'd like to present the following revised charter to the community
> (and with Jari's approval) to the IESG for review.  This charter
> represents discussion on the LISP list and in the LISP session at IETF
> 74.
>
>
>
>
> 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, (where you are attached to
> the network) and Identifiers (who you are) in one number
> space: The IP address. 
The sentence "who you are" is rather confusing to me although its 
intention is certainly to be a simple and catchy explanation. However, 
"you" - the user (?) is probably not an edge interface designator. "who 
you are" suggests that the identifier has something to do with the 
identity of some device or its owner (whoever "you" is) that would stay 
the same when moving around which is clearly not the case in this context.

Wouldn't it be clearer to say: core Routing Locators (which describe 
"where"  an edge network is attached to the Internet core) and edge 
interface designators (which describe to "which" interface a device is 
attached within an edge network)? I find this easier to understand and 
according to my understanding this is 100% in line with the third 
paragraph of the charter.

What's LISP's intended functionality beyond a protocol to separate core 
routing locators (RLocs) and edge interface designators (EIDs)? At 
least, this way all acronyms can be saved without keeping the ambiguous 
and misleading word identifier. Or is that too narrow minded and am I 
missing potential future extensions of LISP that are not documented in 
the charter?

Well, it's probably too late for changes anyway.

Just my 2 cents,

    Michael

> 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  locators and identifiers, thus allowing
> for efficient aggregation of the routing locator space and providing
> persistent identifiers in the  identifier space.
>
> LISP supports the separation of the Internet address space following a
> network-based map-and-encapsulate scheme (RFC 1955).  In LISP, both
> identifiers and locators are IP addresses. In LISP, identifiers are
> composed of two parts: a "global" portion that uniquely identifies a
> particular site and a "local" portion that identifies an interface
> within a site.  The "local" portion may be subdivided to identify a
> particular network within the site.  For a given identifier, LISP maps
> the "global" portion of the identifier into a set of locators that can
> be used by de-capsulation devices to reach the identified interface; as a consequence a host would
> typically change identifiers when it moves from one site to another or
> whenever it moves from one subnet to another within an
> site. Typically, the same IP address will not be used as an identifier
> and locator in LISP.
>
> LISP requires no changes to end-systems or to most routers.  LISP aims
> for an incrementally deployable protocol.
>
> 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) as well as the
> manageability and operability of LISP.
>
> 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
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>   

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: [phone], fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn