Subject: [lisp] My proposed revisions to the charter

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Mar 2009 20:08:44 -0400

Here is a proposed update to the charter that I hope addresses the
concerns raised on the list.  I want to stress that right now, this is
just my comments.  I have not run this by anyone else yet.  So, I
probably got things horribly wrong.

First, I remove acronyms from the discussion of ID/LOC splits.

Darrel discussed an idea with the authors of expanding EID as end-site
identifier.  I've picked that up in this version of the charter.

I've significantly expanded the discussion of LISP to describe what
EIDs are within the scope of this WG and some of their properties.

    I've also included a paragraph that I believe gives the three
basic design constraints of LISP.  I want that in the charter because
I believe it is a scope limitation that will help the chairs.  I want
to stress that this proposed change is something I have not seen
others asking for.

Comments very welcome.

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 Endpoint 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 location and identity, thus allowing
for efficient aggregation of the routing locator space and providing
persistent identity in the identifier space.

LISP supports the separation of the Internet address space into
end-site Identifiers (EIDs) and Routing Locators (RLOCs) following a
network-based map-and-encapsulate scheme (RFC 1955).  Both LISP EIDs
and RLOCs are IP addresses.  LISP EIDs are composed of three parts: a
portion that identifies an organization, a portion that identifies a
subnet within an organization, and a portion that identifies an
interface on that subnet.  LISP maps only the upper portion of the
EID; as a consequence a host would typically change EIDs when it moves
from one organization to another or whenever it moves from one subnet
to another within an organization.  Generally, the same IP address
cannot be used as both an EID and an RLOC, especially if the entities
named by the EID and RLOC are different.

LISP requires no changes to end-systems or to most routers.  LISP aims
for an incrimentally 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).

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2009 13:55:36 +1300

Sam,

As already hinted, I've written my last comment on terminology.

The charter as written is completely neutral about IPv4 versus IPv6.
I hope that doesn't conceal a hidden assumption. It might be
wise to specify that both IPv4 and IPv6 will be supported.
I would leave the question of mixed IPv4/IPv6 support aside for now,
since so much else is bubbling in the v4/v6 coexistence area.

    Brian

---

From: Michael Menth <[email-masked]>
Date: Tue, 24 Mar 2009 02:01:51 +0100

Hi Sam,

I am a bit puzzled about this part of the charter.
> LISP EIDs are composed of three parts: a
> interface on that subnet.  
That makes the fact explicit that LISP EIDs are local locators. I 
thought this should not be the case, at least in theory in the long-term 
given the vision of LISP-in-the-hosts. Is that limitation required? 
What's the motivation behind it? Can the charter also do without it?

> LISP maps only the upper portion of the
> EID; 
What is the upper portion of this triple? The organization or the 
"interface identifier on that subnet"? What does this imply for mapping 
systems? Do they map (a) organization identifiers or (b) subnet 
interface identifiers to RLOCs then?

(a) means that all EIDs of an organization have the same RLOCs. So it's 
rather a site of an organization, right?
(b) means that "interfce identerfiers on that subnet" are globally 
unique, but that cannot be.

> as a consequence a host would typically change EIDs when it moves
> to another within an organization.  
Does that mean that the EID is not bound to a special device, but to a 
location? If I get the assumption right, LISP seems to me more like a 
separation of global and site routing than separation of a locator and 
identifier since my intuitive understanding of an identifier is 
something that is independent of the location - or can be at least in 
theory somewhen in the far future.

Sorry if the answers to my questions are trivial. I may have missed 
something in the previous discussions.

Regards,

    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: Scott Brim <[email-masked]>
Date: Mon, 23 Mar 2009 18:18:14 -0700

> The separation aims to decouple location and identity, thus allowing

s/identity/identification/

> persistent identity in the identifier space.

It is not clear that any "persistent identity" is needed beyond domain
names and URIs, so I would suggest that the charter just sidestep the
issue:

  for efficient aggregation of the routing locator space and providing
  for location-independent identification.

swb

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Mar 2009 21:19:03 -0400

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

    Michael> Hi Sam, I am a bit puzzled about this part of the
    Michael> charter.
    >> LISP EIDs are composed of three parts: a portion that
    >> identifies an organization, a portion that identifies a subnet
    >> within an organization, and a portion that identifies an
    Michael> That makes the fact explicit that LISP EIDs are local
    Michael> locators. 

This clarification is the one thing I'm fairly sure we have consensus to do:-)

    Michael> I thought this should not be the case, at least
    Michael> in theory in the long-term given the vision of
    Michael> LISP-in-the-hosts. Is that limitation required? What's
    Michael> the motivation behind it? Can the charter also do without
    Michael> it?
Several people have asked for this clarification, so my motivation was to address comments we've received.

LISP-in-the-host is something I at least hope is out of scope for this
WG.  We're defining today's LISP.  We will recharter when we change
assumptions like we're talking about here.
So, the point of putting this in the charter is that we want to have an explicit charter change (and thus an explicit level-set) with the IETF community if any of these assumptions change.

I could see a future charter talking about how while LISP in RFC xxxx
only mapped organizations, there is a desire to create an extension to
LISP to bring EID mapping down to the host.  That would be a major
rechartering and would require significant community discussion.

    >> LISP maps only the upper portion of the EID;
    Michael> What is the upper portion of this triple? The
    Michael> organization or the "interface identifier on that
    Michael> subnet"? 
The organization.  Organization is probably not the best term;
end-site might be a better term actually.

    Michael> What does this imply for mapping systems? Do
    Michael> they map (a) organization identifiers or (b) subnet
    Michael> interface identifiers to RLOCs then?
I'm still coming up to speed.
I *think* it's a bit more complicated than that.

    Michael> (a) means that all EIDs of an organization have the same
    Michael> RLOCs. So it's rather a site of an organization, right?
Rightish at least, possibly even completely right.

    >> as a consequence a host would typically change EIDs when it
    >> moves from one organization to another or whenever it moves
    >> from one subnet to another within an organization.
    Michael> Does that mean that the EID is not bound to a special
    Michael> device, but to a location? If I get the assumption right,
    Michael> LISP seems to me more like a separation of global and
    Michael> site routing than separation of a locator and identifier
    Michael> since my intuitive understanding of an identifier is
    Michael> something that is independent of the location - or can be
    Michael> at least in theory somewhen in the far future.

Today's LISP EIDs definitely do seem to include aspects both of local
location and of identification.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Mar 2009 21:22:26 -0400

I'd appreciate others' comments.

I support both of Scott's changes below.
>>>>> "Scott" == Scott Brim <[email-masked]> writes:

    Scott> Excerpts from Sam Hartman on Mon, Mar 23, 2009 08:08:44PM
    Scott> -0400:
    >> The basic idea behind the separation that the Internet
    >> architecture combines two functions, Routing Locators, (where
    >> you are attached to the network) and Endpoint 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 location and identity, thus allowing

    Scott> s/identity/identification/

    >> for efficient aggregation of the routing locator space and
    >> providing persistent identity in the identifier space.

    Scott> It is not clear that any "persistent identity" is needed
    Scott> beyond domain names and URIs, so I would suggest that the
    Scott> charter just sidestep the issue:

    Scott>   for efficient aggregation of the routing locator space
    Scott> and providing for location-independent identification.

    Scott> swb

---

From: Robin Whittle <[email-masked]>
Date: Tue, 24 Mar 2009 13:45:54 +1100

Hi Sam,

I support the critiques of your new text by Michael Menth and Scott
Brim:

   http://www.ietf.org/mail-archive/web/lisp/current/msg00317.html
   http://www.ietf.org/mail-archive/web/lisp/current/msg00318.html

I think it involves too much low level detail and that quite a few of
those details are incorrect or not conducive to either explaining
LISP or to clearly defining the scope of the WG.

I share Noel's concern about being unable to understand the
difference between what he asked for and what you offered, which you
apparently consider to be different:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00322.html

I think the suggestions I made:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00286.html

would be better than the new text you added, for reasons I discussed
here:

   http://www.ietf.org/mail-archive/web/lisp/current/msg00298.html
   http://www.ietf.org/mail-archive/web/lisp/current/msg00309.html

  - Robin

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 24 Mar 2009 10:32:10 -0700

> I would leave the question of mixed IPv4/IPv6 support aside 
> for now, since so much else is bubbling in the v4/v6 coexistence area.
> 

Brian, 

>From my perspective the LISP core specs are very explicit in their
support for both IPv4 and IPv6.  In addition to specifying this same-AFI
encapsulation (4-to-4 over 4 and 6-to-6 over 6) they also are explicit
in supporting both the encapsulation IPv6 EIDs in LISP packets which
have IPv4 RLOCs (6-to-6 over 4), and the encapsulation of IPv4 EIDs in
LISP packets witch have IPv6 RLOCs (4-to-4 over 6).   These capabilities
seem to me an important response to the protocol's stated design goals
incremental deployability and practical utility.

I personally don't think that the charter needs to dive into this level
of detail - but if you think so perhaps you could offer some suggested
text?

-Darrel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Mar 2009 07:16:10 +1300

> of detail - but if you think so perhaps you could offer some suggested

Darrel,

Thanks. The most I would suggest is that the second occurrence of "IP" becomes
"IPv4 or IPv6", so we'd have
   Both LISP EIDs and RLOCs are IPv4 or IPv6 addresses.

    Brian

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 24 Mar 2009 13:24:24 -0700

> > I personally don't think that the charter needs to dive into this 
> > level of detail - but if you think so perhaps you could offer some 
> > suggested text?
> 
> Darrel,
> 

Thanks Brian, I find that very reasonable.

-Darrel