|
RE: [lisp] LISP: update to charter in external review
2009-03-30 13:35:00
-----Original Message-----
From: lisp-bounces(_at_)ietf(_dot_)org
[mailto:lisp-bounces(_at_)ietf(_dot_)org] On
Behalf Of Dow Street
Sent: Monday, March 30, 2009 6:31 AM
To: Sam Hartman
Cc: lisp(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
iesg(_at_)ietf(_dot_)org
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
lisp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|