Subject: Re: [lisp] LISP (re-)Charter discussion

From: Terry Manderson <[email-masked]>
Date: Wed, 19 Oct 2011 16:23:26 -0700

Hi All,

Joel and I bounced the following charter around and have also passed it in
front of AD's eyes.

You obviously have time to chew on this for a while before Taipei.

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 other
contexts. The IRTF RRG examined several proposals, some of which were
published as IRTF-track Experimental RFCs.

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 LISP and the various LISP 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.

Goals and Milestones

Jun 2012    Forward draft-ietf-lisp-mib to the IESG.
Jun 2012    Forward draft-ietf-lisp-sec to the IESG.
Jun 2012    Forward draft-ietf-lisp-deployment to the IESG.
Jun 2012    Forward a security proposal document (draft-ietf-lisp-threats)
            to the IESG.

Dec 2013    Forward to the IESG an operational set of documents which should
            include cache management and ETR synchronization
            techniques inclusive of a cache management specification.

Jun 2014    Forward to the IESG an evaluation of the security threat to
            cache management and ETR synchronization.
Jun 2014    Evaluate the applicability and coverage for LISP from a
            reuse of SIDR technology.

Dec 2014    Re-charter or close

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Wed, 26 Oct 2011 22:10:42 -0700

WG hat on.

This follow-up is initiated due to a recent observation gleaned from a
presentation request for the Taipei meeting.

While this draft charter does not preclude taking on work items specifically
related to LISP VPN or LISP mobility, I think it's useful to tease out the
questions and put them to the WG for discussion.

Should LISP mobility be specifically included in the work plan?

Should LISP VPN modalities be specifically included in the work plan?

Cheers
Terry

On 20/10/11 9:23 AM, "Terry Manderson" <[email-masked]> wrote:

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

---

From: Albert Cabellos <[email-masked]>
Date: Fri, 28 Oct 2011 19:04:50 +0200

Hi,

> Should LISP mobility be specifically included in the work plan?

I would like to point out that we have a small but growing community of 
people interested into LISPmob, we open-sourced the code 1.5 months ago.

Albert

> On 20/10/11 9:23 AM, "Terry Manderson"<[email-masked]>  wrote:
>
>> Hi All,
>>

---

From: Terry Manderson <[email-masked]>
Date: Sun, 30 Oct 2011 21:20:21 -0700

Hi Albert,

> people interested into LISPmob, we open-sourced the code 1.5 months ago.

To be clear (as in crystal) does this mean you think that mobility should be
included? or are you simply making the observation that there is a community
of people 'out there' who are yet to be vocal on this ML.

Cheers
Terry

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 31 Oct 2011 13:25:27 -0700

Terry,

> Joel and I bounced the following charter around and have also passed it in

couple of comment in-line...

> manageability and operability of LISP.

The charter needs to explicitly include in the Goals and Milestones the
document(s) that cover the analysis.

Furthermore, as John Scudder asked in his e-mail on 9/28, "the base
spec calls out a number of areas that require more experimentation.
A simple grep will find these. These experiments and what has been
learned from them should be documented.  The same applies if other
specs have similar caveats (I just haven't looked for them)."
The charter needs to explicitly include in the Goals and Milestones 
the document(s) that cover this.

Yakov.

> Dec 2014    Re-charter or close

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 31 Oct 2011 13:31:03 -0700

Terry,

> Should LISP VPN modalities be specifically included in the work plan?

If LISP VPN modality is an L2VPN, then such work should be pursued
in L2VPN WG.

If LISP VPN modality is an L3VPN, then such work should be pursued
in L3VPN WG.

Thus both of of the above LISP VPN modalities should be outside the
scope of the LISP WG.

Yakov.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Nov 2011 01:57:45 +0200

Yakov,

> the document(s) that cover this.

I would love to see documents in the charter that describe experiences from simulation/implementation/measurement/real-world use, and shed light on these issues.

Jari

---

From: Terry Manderson <[email-masked]>
Date: Mon, 31 Oct 2011 18:25:06 -0700

Yakov,

> the document(s) that cover this.

I missed that - thanks for bringing it up again..

I'll send an update in a few days.

Terry

---

From: Terry Manderson <[email-masked]>
Date: Mon, 31 Oct 2011 18:54:29 -0700

Yakov,

> Thus both of of the above LISP VPN modalities should be outside the

Just to keep you (and the list) in the loop, I have escalated this question
to the routing and internet area ADs.

When I have a sense of their opinions I will respond further.

Cheers
Terry