[lisp] base specification, working group charter

Tue, 14 Feb 2012 14:14:20 -0800 

I have some news for you. The LISP base specification has just been approved 
yesterday, joining the three other documents from this working group that had 
already been approved earlier. We'll be working with the remaining two in the 
coming weeks.

The other piece of news is that the IESG has reviewed and discussed your 
proposed charter, and had a number of suggested changes. The main thrust of the 
changes is as follows:

1) Cut down the number of items to stay focused; the IESG felt that there was 
too much material in the proposed charter.

2) Make some items priority 1 deliverables and add some items that are 
important. The IESG felt that as it had reviewed the base specifications, it 
now had a good view of what documentation there is on LISP and is still 
missing. In particular, it was felt that an architecture specification that 
paints some of the bigger picture would be valuable.

Please find attached the proposed charter revision from the IESG along with a 
diff file to the one that was circulated in the WG list some time ago.

We plan to approve this charter in the near future, if you have any objections 
please bring them up as soon as possible either on the WG mailing list or to 
[email protected]

Jari
Title: Diff: charter-original-proposal.txt - charter-new-proposal-from-the-iesg-ver2.txt
 charter-original-proposal.txt   charter-new-proposal-from-the-iesg-ver2.txt 
Locator/ID Separation Protocol (lisp) Locator/ID Separation Protocol (lisp)
------------------------------------- -------------------------------------
Current Status: Active Current Status: Active
Last updated: 2012-01-19 Last updated: 2012-02-14
Chairs: Chairs:
Joel Halpern <[email protected]> Joel Halpern <[email protected]>
Terry Manderson <[email protected]> Terry Manderson <[email protected]>
Internet Area Directors: Internet Area Directors:
Ralph Droms <[email protected]> Ralph Droms <[email protected]>
Jari Arkko <[email protected]> Jari Arkko <[email protected]>
Internet Area Advisor: Internet Area Advisor:
skipping to change at line 46 skipping to change at line 46
The basic idea behind the separation is that the Internet architecture The basic idea behind the separation is that the Internet architecture
combines two functions, routing locators, (where you are attached to the combines two functions, routing locators, (where you are attached to the
network) and identifiers (who you are) in one number space: The IP network) and identifiers (who you are) in one number space: The IP
address. Proponents of the separation architecture postulate that address. Proponents of the separation architecture postulate that
splitting these functions apart will yield several advantages, including splitting these functions apart will yield several advantages, including
improved scalability for the routing system. The separation aims to improved scalability for the routing system. The separation aims to
decouple locators and identifiers, thus allowing for efficient decouple locators and identifiers, thus allowing for efficient
aggregation of the routing locator space and providing persistent aggregation of the routing locator space and providing persistent
identifiers in the identifier space. identifiers in the identifier space.
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 A number of approaches are being looked at in parallel in other
contexts. The IRTF RRG examined several proposals, some of which were contexts. The IRTF RRG examined several proposals, some of which were
published as IRTF-track Experimental RFCs. published as IRTF-track Experimental RFCs.
The LISP WG is chartered to work on the LISP base protocol, completing 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 the ongoing work, and any items which directly impact LISP protocol
structures and are related to using LISP for improving Internet routing structures and which are related to using LISP for improving Internet routing
scalability. Specifically, the group will work on: scalability. Specifically, the group will work on:
- LISP security threats and solutions - Architecture description: This document will describe the
- MIBs architecture of the entire LISP system, making it easier to read the
- deployment models rest of the LISP specifications and providing a basis for discussion
- allocation of EID space about the details of the LISP protocols.
- alternate mapping system designs
- 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
- Alternate mapping system designs: Develop alternative mapping
designs to be tested.
- Data models for management of LISP.
The first three items 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 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.
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 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
scalability problem at this time. The specifications developed by the WG scalability problem at this time. The specifications developed by the WG
are Experimental and labeled with accurate disclaimers about their are Experimental and labeled with accurate disclaimers about their
limitations and not fully understood implications for Internet traffic. limitations and not fully understood implications for Internet traffic.
In addition, as these issues are understood, the working group will In addition, as these issues are understood, the working group will
analyze and document the implications of LISP on Internet traffic, analyze and document the implications of LISP on Internet traffic,
applications, routers, and security. This analysis will explain what applications, routers, and security.
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. Specifically, the group will work on:
- documenting areas that need experimentation
- summarizing the results of implementation, experiments, and deployment
experience
- describing the implications of employing LISP
- operational guidance for using LISP
Goals and Milestones Goals and Milestones
Jun 2012 Forward draft-ietf-lisp-mib to the IESG September 2012: Submit an architecture description to the IESG for
Jun 2012 Forward draft-ietf-lisp-sec to the IESG publication as an Experimental RFC
Jun 2012 Forward to the IESG an operational document which should
include cache management and ETR synchronization September 2012: Submit a deployment model document to the IESG for
techniques (draft-ietf-lisp-deployment). publication as an Experimental RFC
Oct 2012 Forward to the IESG a document providing a solution
to replay issues with Map-Register/Map-Notify 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
March 2013: Submit a data model (e.g., a MIB) document to the IESG for
publication as an Experimental RFC
 End of changes. 8 change blocks. 
27 lines changed or deleted 49 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/ 
Locator/ID Separation Protocol (lisp)
-------------------------------------
Current Status: Active
Last updated: 2012-02-14

 Chairs:
     Joel Halpern <[email protected]>
     Terry Manderson <[email protected]>

 Internet Area Directors:
     Ralph Droms <[email protected]>
     Jari Arkko <[email protected]>

 Internet Area Advisor:
     Jari Arkko <[email protected]>

 Secretaries:
     Wassim Haddad <[email protected]>
     Luigi Iannone <[email protected]>

 Mailing Lists:
     General Discussion: [email protected]
     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

- Alternate mapping system designs: Develop alternative mapping
  designs to be tested.

- Data models for management of LISP.

The first three items 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

March 2013: Submit a data model (e.g., a MIB) document to the IESG for
publication as an Experimental RFC

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to