Thanks for your feedback, John. Would a modified charter with these changes work for you: Jari
Locator/ID Separation Protocol (lisp)
-------------------------------------
Current Status: Active
Last updated: 2012-03-08
Chairs:
Joel Halpern <jmh@xxxxxxxxxxxxxxx>
Terry Manderson <terry.manderson@xxxxxxxxx>
Internet Area Directors:
Ralph Droms <rdroms.ietf@xxxxxxxxx>
Jari Arkko <jari.arkko@xxxxxxxxx>
Internet Area Advisor:
Jari Arkko <jari.arkko@xxxxxxxxx>
Secretaries:
Wassim Haddad <Wassim.Haddad@xxxxxxxxxxxx>
Luigi Iannone <luigi@xxxxxxxxxxxxxxxxxxxxxxx>
Mailing Lists:
General Discussion: lisp@xxxxxxxx
To Subscribe: https://www.ietf.org/mailman/listinfo/lisp
Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html
Description of Working Group:
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. 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.
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 has completed the first set of Experimental RFCs
describing the Locator/ID Separation Protocol. LISP requires no
changes to end-systems or to routers that do not directly participate
in the LISP deployment. LISP aims for an incrementally deployable
protocol.
The LISP WG is chartered to continue work on the LISP base protocol, completing
the ongoing work, and any items which directly impact LISP protocol
structures and which are related to using LISP for improving Internet routing
scalability. Specifically, the group will work on:
- Architecture description: This document will describe the
architecture of the entire LISP system, making it easier to read the
rest of the LISP specifications and providing a basis for discussion
about the details of the LISP protocols.
- Deployment models: This document will describe what kind of
deployments can be expected for LISP, and give operational advice on
how they can be set up.
- A description of the impacts of LISP: This document will describe
the problems that LISP is intended to address and the impacts that
employing LISP has. While the work on LISP was initiated by Internet
routing scaling concerns, there has also been an interest on
improved solutions to a number of different problems, such as
traffic engineering. This document should describe problem areas
(such as scaling or traffic engineer) where LISP is expected to have
a positive effect, as well as any tradeoffs that are caused by
LISP's design.
- LISP security threats and solutions: This document will describe the
security analysis of the LISP system, what issues it needs to
protect against, and a solution that helps defend against those
issues. The replay attack problem discussed on the mailing list
should be included in this work.
- Allocation of Endpoint IDentifier (EID) space: This document
requests address space to be used for the LISP experiment as
identifier space
- Provide example specifications for performing cache management
and ETR synchronization.
- Alternate mapping system designs: Develop alternative mapping
designs to be tested.
- Data models for management of LISP.
The first three items (architecture, deployment models, impacts) need
to be completed first before other items can be submitted as RFCs. The
three first documents also need to complement each other, by
describing how the architecture supports a solution for a particular
problem area and how the solution can be deployed to help with that
problem.
In addition, if work chartered in some other IETF WG requires changes
in the LISP base protocol or any items which directly impact LISP
protocol structures, then the LISP WG is chartered to work on such
changes.
It is expected that the results of specifying, implementing, and testing
LISP will be fed to the general efforts at the IETF and IRTF to
understand which type of a solution is optimal. The LISP WG is not
chartered to develop a standard solution for solving the routing
scalability problem at this time. The specifications developed by the WG
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.
Goals and Milestones
September 2012: Submit an architecture description to the IESG for
publication as an Experimental RFC
September 2012: Submit a deployment model document to the IESG for
publication as an Experimental RFC
September 2012: Submit a LISP impact discussion document to the IESG
for publication as an Experimental RFC
October 2012: Submit a LISP threats analysis document to the IESG for
publication as an Experimental RFC
October 2012: Submit an EID allocation document to the IESG for
publication as an Experimental RFC
January 2013: Submit an lternate mapping system designs to the IESG
for publication as an Experimental RFC
January 2013: Publish an example cache management specification.
January 2013: Publish an example ETR synchronization specification.
March 2013: Submit a data model (e.g., a MIB) document to the IESG for
publication as an Experimental RFC
March 2013: Summarize results of specifying, implementing, and testing
LISP and forward to IESG and/or IRTF.
Title: Diff: charter-as-proposed.txt - charter-as-modified.txt
| charter-as-proposed.txt | charter-as-modified.txt | |||
|---|---|---|---|---|
| Locator/ID Separation Protocol (lisp) | Locator/ID Separation Protocol (lisp) | |||
| ------------------------------------- | ------------------------------------- | |||
| Current Status: Active | Current Status: Active | |||
| Last updated: 2012-02-14 | Last updated: 2012-03-08 | |||
| Chairs: | Chairs: | |||
| Joel Halpern <jmh@xxxxxxxxxxxxxxx> | Joel Halpern <jmh@xxxxxxxxxxxxxxx> | |||
| Terry Manderson <terry.manderson@xxxxxxxxx> | Terry Manderson <terry.manderson@xxxxxxxxx> | |||
| Internet Area Directors: | Internet Area Directors: | |||
| Ralph Droms <rdroms.ietf@xxxxxxxxx> | Ralph Droms <rdroms.ietf@xxxxxxxxx> | |||
| Jari Arkko <jari.arkko@xxxxxxxxx> | Jari Arkko <jari.arkko@xxxxxxxxx> | |||
| Internet Area Advisor: | Internet Area Advisor: | |||
| skipping to change at line 90 | skipping to change at line 90 | |||
| - LISP security threats and solutions: This document will describe the | - LISP security threats and solutions: This document will describe the | |||
| security analysis of the LISP system, what issues it needs to | security analysis of the LISP system, what issues it needs to | |||
| protect against, and a solution that helps defend against those | protect against, and a solution that helps defend against those | |||
| issues. The replay attack problem discussed on the mailing list | issues. The replay attack problem discussed on the mailing list | |||
| should be included in this work. | should be included in this work. | |||
| - Allocation of Endpoint IDentifier (EID) space: This document | - Allocation of Endpoint IDentifier (EID) space: This document | |||
| requests address space to be used for the LISP experiment as | requests address space to be used for the LISP experiment as | |||
| identifier space | identifier space | |||
| - Provide example specifications for performing cache management | ||||
| and ETR synchronization. | ||||
| - Alternate mapping system designs: Develop alternative mapping | - Alternate mapping system designs: Develop alternative mapping | |||
| designs to be tested. | designs to be tested. | |||
| - Data models for management of LISP. | - Data models for management of LISP. | |||
| The first three items need to be completed first before other items | The first three items (architecture, deployment models, impacts) need | |||
| can be submitted as RFCs. The three first documents also need to | to be completed first before other items can be submitted as RFCs. The | |||
| complement each other, by describing how the architecture supports a | three first documents also need to complement each other, by | |||
| solution for a particular problem area and how the solution can be | describing how the architecture supports a solution for a particular | |||
| deployed to help with that problem. | problem area and how the solution can be deployed to help with that | |||
| problem. | ||||
| In addition, if work chartered in some other IETF WG requires changes | In addition, if work chartered in some other IETF WG requires changes | |||
| in the LISP base protocol or any items which directly impact LISP | in the LISP base protocol or any items which directly impact LISP | |||
| protocol structures, then the LISP WG is chartered to work on such | protocol structures, then the LISP WG is chartered to work on such | |||
| changes. | changes. | |||
| It is expected that the results of specifying, implementing, and testing | It is expected that the results of specifying, implementing, and testing | |||
| LISP will be fed to the general efforts at the IETF and IRTF to | LISP will be fed to the general efforts at the IETF and IRTF to | |||
| understand which type of a solution is optimal. The LISP WG is not | understand which type of a solution is optimal. The LISP WG is not | |||
| chartered to develop a standard solution for solving the routing | chartered to develop a standard solution for solving the routing | |||
| skipping to change at line 137 | skipping to change at line 141 | |||
| October 2012: Submit a LISP threats analysis document to the IESG for | October 2012: Submit a LISP threats analysis document to the IESG for | |||
| publication as an Experimental RFC | publication as an Experimental RFC | |||
| October 2012: Submit an EID allocation document to the IESG for | October 2012: Submit an EID allocation document to the IESG for | |||
| publication as an Experimental RFC | publication as an Experimental RFC | |||
| January 2013: Submit an lternate mapping system designs to the IESG | January 2013: Submit an lternate mapping system designs to the IESG | |||
| for publication as an Experimental RFC | for publication as an Experimental RFC | |||
| January 2013: Publish an example cache management specification. | ||||
| January 2013: Publish an example ETR synchronization specification. | ||||
| March 2013: Submit a data model (e.g., a MIB) document to the IESG for | March 2013: Submit a data model (e.g., a MIB) document to the IESG for | |||
| publication as an Experimental RFC | publication as an Experimental RFC | |||
| March 2013: Summarize results of specifying, implementing, and testing | ||||
| LISP and forward to IESG and/or IRTF. | ||||
| End of changes. 5 change blocks. | ||||
| 6 lines changed or deleted | 14 lines changed or added | |||
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ | ||||
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf