Subject: [lisp] LISP: update to charter in external review

From: Sam Hartman <[email-masked]>
Date: Sun, 29 Mar 2009 23:29:56 -0400

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. 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
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

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

---

From: Dow Street <[email-masked]>
Date: Sun, 29 Mar 2009 21:30:54 -0700

On Mar 29, 2009, at 8:29 PM, Sam Hartman wrote:

> 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)

> Proponents of the separation architecture

---

From: Damien Saucez <[email-masked]>
Date: Mon, 30 Mar 2009 08:34:39 +0200

Sam Hartman wrote:

[snip]
> Mar 2010 Submit base ALT specification to the IESG as Experimental
Would it be better to write "Submit mapping system(s) specification to 
the IESG as Experimental"? I think it would be interesting to propose 
ALT and an alternative to ALT.

> June 2010 Submit Recommendations for Securing the LISP Mapping System to
Can we really propose the LISP specification in March and wait June for 
the security? What if we need to modify some messages to support the 
security?

Damien Saucez
> Dec 2010 Re-charter or close.
[snip]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Mar 2009 08:33:05 -0700

Folks,

The subject of MTU handling in LISP has come up a number
of times. Below is a proposed rewrite of Section 5.4 which
I believe addresses the issues.

Any comments?

Fred
[email-masked]

5.4.  LISP Tunnel MTU Determination

5.4.1 ITR Specification

The inner IP layer presents packets of various sizes to the ITR for
LISP encapsulation. These packets may be either fragmentable (i.e.,
an IPv4 packet with the Don't Fragment (DF) bit set to 0) or
unfragmentable (i.e., an IPv6 packet, or an IPv4 packet with DF=1).
For each packet, the inner IP layer must determine whether to
1) admit the packet into the tunnel, 2) fragment the packet, then
admit each fragment into the tunnel, or 3) drop the packet and
return an ICMP "Packet Too Big (PTB)" message to the original source.

The tunnel interface maintains a static MTU (S_MTU) of 1500 bytes
minus the size of the encapsulating LISP/UDP/IP headers. The
tunnel MAY additionally maintain per-ETR MTUs (ETR_MTU) using
dynamic MTU determination [RFC1191][RFC1981].

When the inner IP layer presents an unfragmentable packet to the
tunnel, it admits the packet if it is no larger than
MAX(S_MTU, ETR_MTU);  otherwise, it drops the packet and returns
an ICMP PTB message to the original source. When the inner IP
layer presents a fragmentable packet to the tunnel, it first uses
IP fragmentation if necessary to break the packet into fragments
that are no larger than S_MTU, then admits each fragment into
the tunnel.

After a packet (or fragment) has been admitted into the tunnel,
the ITR encapsulates it in the requisite LISP/UDP/IP headers and
sets DF=0 in the outer IP header (when IPv4 is used as the outer
IP protocol). The ITR then forwards the encapsulated packet to ETR.

After sending packets, the ITR may receive LISP-encapsulated ICMP
PTB messages from an ETR. The ITR verifies that the message
corresponds to a packet it sent earlier by examining the LISP
nonce, source and destination addresses, etc. in the packet-in-
error. The ITR then sets ETR_MTU to the maximum of the MTU value
encoded in the ICMP PTB message and S_MTU. It then transcribes
the message into a corresponding PTB message to send back to the
original source. 

When IPv6 is used as the outer protocol, the ITR may also receive
ICMP PTB messages from a router on the path the the ETR. The ITR
verifies that the PTB corresponds to an actual data packet as
above, and returns a transcribed ICMP PTB back to the original
source.

5.4.2  ETR Specification
   
When the ETR receives an IP packet, it first checks whether it
was fragmented in the network by examining the MF bit and Offset
fields in the outer IP header. If the packet is the first-fragment
(i.e., with MF==1 and Offset==0) of a LISP data packet addressed
to one of the router's RLOC addresses, the ETR prepares a LISP-
encapsulated ICMP PTB message to send back to the ITR (subject
to rate limiting).

The ETR copies the leading portion of the first-fragment into the
packet-in-error field of the ICMP PTB message up to a total message
size of 576 bytes minus the size of the encapsulating LISP/UDP/IP
headers. The ETR then encapsulates the message in outer LISP/UDP/IP
headers and sends it back to the ITR.

Following the first-fragment processing described above, the
ETR discards all IP fragments addressed to one of the its RLOC
addresses.

5.4.3  MTU Probing

The ITR may periodically probe the path MTU to the ETR by
generating a dummy LISP packet wit MF==1 and Offset==0 in the
outer IP header. (When IPv4 is used as the outer protocol, it
also sets DF=0.) If the ETR receives the probe, it will discard
it and return a LISP-encapsulated ICMP PTB message.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 30 Mar 2009 19:33:24 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dow Street
> Sent: Monday, March 30, 2009 6:31 AM
> To: Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [lisp] LISP: update to charter in external review
> 
> 

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.
> > be used by de-capsulation devices to reach the identified 
> interface;  
> > as a consequence a host would
> > All proposals (including LISP) have potentially harmful 
> side-effects  
> > to
> > it is not yet known what kind of design alternative is the 
> best one  
> > among
> > many.
> >
> > used to understand the characteristics of these designs. 
> The LISP WG  
> > is
> > (draft-farinacci-lisp-multicast-01.txt) for these purposes, 
> with the  
> > given
> > interoperable LISP implementations as well as defining 
> requirements  
> > for

---

From: Michael Menth <[email-masked]>
Date: Tue, 31 Mar 2009 00:24:23 +0200

Hi Sam,

> the network) and Identifiers (who you are) in one number
The sentence "who you are" is rather confusing to me although its 
intention is certainly to be a simple and catchy explanation. However, 
"you" - the user (?) is probably not an edge interface designator. "who 
you are" suggests that the identifier has something to do with the 
identity of some device or its owner (whoever "you" is) that would stay 
the same when moving around which is clearly not the case in this context.

Wouldn't it be clearer to say: core Routing Locators (which describe 
"where"  an edge network is attached to the Internet core) and edge 
interface designators (which describe to "which" interface a device is 
attached within an edge network)? I find this easier to understand and 
according to my understanding this is 100% in line with the third 
paragraph of the charter.

What's LISP's intended functionality beyond a protocol to separate core 
routing locators (RLocs) and edge interface designators (EIDs)? At 
least, this way all acronyms can be saved without keeping the ambiguous 
and misleading word identifier. Or is that too narrow minded and am I 
missing potential future extensions of LISP that are not documented in 
the charter?

Well, it's probably too late for changes anyway.

Just my 2 cents,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Sam Hartman <[email-masked]>
Date: Mon, 30 Mar 2009 22:40:55 -0400

>>>>> "Michael" == Michael Menth <[email-masked]> writes:

    Michael> The sentence "who you are" is rather confusing to me
    Michael> although its intention is certainly to be a simple and
    Michael> catchy explanation. However, "you" - the user (?) is
    Michael> probably not an edge interface designator. "who you are"
    Michael> suggests that the identifier has something to do with the
    Michael> identity of some device or its owner (whoever "you" is)
    Michael> that would stay the same when moving around which is
    Michael> clearly not the case in this context.

    Michael> Wouldn't it be clearer to say: core Routing Locators
    Michael> (which describe "where" an edge network is attached to
    Michael> the Internet core) and edge interface designators (which
    Michael> describe to "which" interface a device is attached within
    Michael> an edge network)? I find this easier to understand and
    Michael> according to my understanding this is 100% in line with
    Michael> the third paragraph of the charter.

the second paragraph is intended to be far more general than LISP and
carefully avoids using any LISP terms.  I think it is accurate,
although the pronoun "you" is unbound.  For LISP, it's an edge network
(in your vocabulary),a site in others' vocabulary, etc.  For HIPP, you
is bound to a something.  Some people would probably say stack,
although that's misleading as HIP explicitly supports stacks with
multiple HITs.  For shim6, you is bound to something close to stack,
although it's a bit more complicated than that.

The second paragraph has not undergone a lot of editing other than to
remove LISP-specific terms from the general description.  However, it
also has not drawn a lot of fire.  If you do try to build consensus
behind a change, I strongly recommend against introducing new terms or
acronym expansions.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 30 Mar 2009 22:59:00 -0400

>>>>> "Damien" == Damien Saucez <[email-masked]> writes:

    Damien> Would it be better to write "Submit mapping system(s)
    Damien> specification to the IESG as Experimental"? I think it
    Damien> would be interesting to propose ALT and an alternative to
    Damien> ALT.
Under the current charter, proposing an alternative mapping system
besides alt is out of scope.  At the meeting, Jari indicated that this
is intentional and that he does not want to expand our scope to
consider new mapping systems.
    Damien> Can we really propose the LISP specification in March and
    Damien> wait June for the security? What if we need to modify some
    Damien> messages to support the security?

We'll have to be fairly careful about this.  I'm assuming that
security document is an analysis/description/future work document.  To
the extent that we need to do security work that affects protocol
messages, it will need to be part of the base spec.

---

From: Michael Menth <[email-masked]>
Date: Tue, 31 Mar 2009 22:44:48 +0200

Sam Hartman schrieb:
> carefully avoids using any LISP terms.  

Indeed, the second paragraph does not yet contain the word LISP, that's 
true, but somehow my expectation was that the second paragraph of the 
charter must be about LISP.  And my expectation was confirmed by the 
word "Routing Locator" (uppercase) instead of simply "locator" 
(lowercase) and Identifier (uppercase) instead of "identifier" 
(lowercase). I read both uppercase words as proper names of a specific 
architecture which was LISP for me in this context. So, the removal of 
LISP-specific or LISP-like nomenclature was not yet fully successful. 
But I don't think that this was the major problem.

> I think it is accurate,
> also has not drawn a lot of fire.  

The unbound pronoun "you" really puzzled me. Your interpretation of the 
"you" with the examples of the other architectures makes sense to me, 
but the text says nothing about them. I rather read the text "Identifier 
(who you are)" as an implicit definition of what an identifier is, 
namely a name that has something to do with my identity or that of my 
devices. I found this implicit definition a contradition to how an 
identifier is used in the third paragraph.

I did not carefully follow all the discussions on this list, but I was 
curious about how the charter looks in the end. And when I saw the new 
charter I was just puzzled about the implicit definition of an 
identifier and its subsequent clarification of the opposite in LISP.

I certainly do not want to propose a specific changes to the charter, I 
was just wondering and wanted to give you feedback. You can apply 
changes if you think that my misunderstanding has something to do with 
the text.

Michael

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Mar 2009 19:16:18 -0400

Sorry, I didn't notice the upper case terms in the second paragraph.
I definitely agree they should be removed.