Terry,
After a receiving the suggestions from Yakov and John, emailing
some ADs,
the draft charter is as follows:
Please review, and highlight any areas missed. I'd like to close
this off by
next Friday (9th Dec), and pass to our AD.
The IAB's October 2006 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 is 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. 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 IPv4 and IPv6 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 approaches are being looked at in parallel in other
contexts. The IRTF RRG examined several proposals, some of which were
published as IRTF-track Experimental RFCs.
The LISP WG is chartered to work on the LISP base protocol and any
items
which directly impact LISP including any base protocol changes
required to
enable VPN and mobile topologies (precise operational definitions of
these topologies should be left for IETF WGs focused on these
technologies).
With respect to chartering LISP WG to work on the LISP "base protocol
changes required to enable VPN", if these changes have to do with
enabling L2 VPNs, then such work should be done in L2VPN WG. If
these changes have to do with enabling L3 VPN, then such work should
be done in L3VPN WG. In both of these cases the outcome of this work
could be reviewed by the LISP WG.
The same should apply to work on enaling "mobile topoligies".
With this in mind I propose to replace the above sentence with the
following:
The LISP WG is chartered to work on the LISP base protocol and any
items
which directly impact LISP and are related to using LISP for
improving
Internet routing scalability.
Yakov.
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
LISP
and the various LISP 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 as well as the
manageability and operability of LISP.
Goals and Milestones
Jun 2012 Forward draft-ietf-lisp-mib to the IESG
Jun 2012 Forward draft-ietf-lisp-sec to the IESG
Jun 2012 Forward to the IESG an operational document which should
include cache management and ETR synchronization
techniques (draft-ietf-lisp-deployment).
Dec 2013 Publish an example cache management specification.
Dec 2013 Forward to the IESG an evaluation of the security
threat to
cache maintenance (draft-ietf-lisp-threats)
Dec 2013 Forward to the IESG a document addressing the areas which
require further experimentation.
Jun 2014 Evaluate the applicability and coverage for LISP from a
reuse of SIDR technology.
Jun 2014 Summarize results of specifying, implementing, and
testing
LISP and forward to IESG and/or IRTF.
Jun 2014 Analyze and document the implications of LISP
deployments in
Internet topologies and forward to IESG for publication.
Dec 2014 Re-charter or close
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
