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

["PAPADIMITRIOU Dimitri" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Dow Street
> Sent: Monday, March 30, 2009 6:31 AM
> To: Sam Hartman
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [lisp] LISP: update to charter in external review
> 
> 
> On Mar 29, 2009, at 8:29 PM, Sam Hartman wrote:
> 
> > 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.
> 
> I don't think the preceding lines form a sentence.  Is there an "is"  
> missing?  Alternatively, here is possible substitute:
> 
> Locator/Identifier separation approaches are rooted in the premise  
> that the current Internet architecture often uses a single IP 
> address  
> (i.e. name) for two distinctly different roles: Routing Locators  
> (which describe "where" you are attached to the network) and  
> Identifiers (which describe "who" you are)

in order to prevent confusion between a name and an address, it would be
preferable to state:

Locator/Identifier separation approaches are rooted in the premise that
the current Internet architecture designates by a single number space,
i.e., the IP address, two distinctly different roles: Routing Locators
(which describe "where" you are attached to the network) and Identifiers
(which describe "who" you are).

Thanks,
-dimitri.
> > 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
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>