Fred, "Authorized" is I think the wrong word to use to describe the
publication. Or at least a misleading word. The IRTF process is such
that the RG did not actually approve the publication of any of the
solutions. The RG Chair sponsored the publication as an output of the
RG. IRTF procedures explicitly recognize and allow for multiple
minority reports from an RG.
I do agree that we should recognize that a number of ideas have been
published as RFCs. And we should probably not be too specific about
what the RG is doing, since that is liable to change.
Yours,
Joel
On 9/28/2011 10:20 PM, Templin, Fred L wrote:
Hi Terry,
Regarding the 5th paragraph of the Draft Charter:
A number of approaches are being looked at in parallel in the IRTF and
IETF. At this time, these proposals are at an early stage.
This needs to be updated; here is a proposed rewrite:
"A number of approaches have been published in parallel in the
IRTF and IETF. In particular, the IRTF Routing Research Group
(RRG) has published its recommendations [RFC6115] and design
goals [RFC6227], and has authorized the publication of three
solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and
ILNP [ILNP]."
Thanks - Fred
[email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Terry Manderson
Sent: Wednesday, September 21, 2011 5:05 PM
To: [email protected]
Subject: [lisp] LISP (re-)Charter discussion
Hi Folks,
In Prague there was no strong consensus on modifying the LISP
Charter from
what it currently is, perhaps only updating the existing
Goals/Milestones.
So no clear decision could be made. What I would like to do
is push out a
'idea generating' draft charter that is _almost_ identical to
what we have
today.
You can find the existing charter here:
https://datatracker.ietf.org/wg/lisp/charter/
The draft is below.
So in light of such an approach, Joel and I discussed some
work items that
came from what was said at the mic in Prague and to us individually.
They are:
* Finish the deployment document
* Get the two security documents done
* Get an operational document at least started, which should include
cache management and ETR synchronization techniques.
* Either in the second security document, or in complementary
documents we
need to evaluate the security threat to cache maintenance, and
evaluate the applicability and coverage we get from a reuse of SIDR
technology.
Is anything not represented here that you believe necessary?
and conversely
is there something here that is out of scope in your eyes?
Are there work areas not covered by the draft below which you
believe should
be?
Draft Charter
------------
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 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 identifier to locator 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 and any items
which directly
impact LISP. 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 as well as the
manageability and operability of LISP.
Cheers
Terry
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
