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

From: Terry Manderson <[email-masked]>
Date: Thu, 1 Dec 2011 17:26:22 -0800

After a receiving the suggestions from Yakov and John, emailing some ADs,
the draft charter is as follows:

Please review, and highlight any areas missed. I'd like to close this off by
next Friday (9th Dec), and pass to our AD.

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 including any base protocol changes required to
enable VPN and mobile topologies (precise operational definitions of
these topologies should be left for IETF WGs focused on these technologies).
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 to the IESG an operational document which should
            include cache management and ETR synchronization
            techniques (draft-ietf-lisp-deployment).
Dec 2013    Publish an example cache management specification.
Dec 2013    Forward to the IESG an evaluation of the security threat to
            cache maintenance (draft-ietf-lisp-threats)
Dec 2013    Forward to the IESG a document addressing the areas which
            require further experimentation.
Jun 2014    Evaluate the applicability and coverage for LISP from a
            reuse of SIDR technology.
Jun 2014    Summarize results of specifying, implementing, and testing
            LISP and forward to IESG and/or IRTF.
Jun 2014    Analyze and document the implications of LISP deployments in
            Internet topologies and forward to IESG for publication.
Dec 2014    Re-charter or close

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Dec 2011 22:28:40 -0800

> not be used as an identifier

This entire paragraph is so misleading and it is not documented in any LISP specification that an identifier is composed of two parts.

Also, in the LISP architecture, an EID or RLOC can be other than an IPv4 or IPv6 address.

And an EID does not need to change when a host moves from one site to another.

So, more to the point, why is this definition in the charter?

Dino

---

From: Terry Manderson <[email-masked]>
Date: Thu, 1 Dec 2011 22:55:54 -0800

Inherited hangover from the last charter...

It can go I think. The awareness of what LISP is, and is not, is
substantially different now than before - so I am happy to trim this section
out.

Cheers
Terry

On 2/12/11 4:28 PM, "Dino Farinacci" <[email-masked]> wrote:

> This entire paragraph is so misleading and it is not documented in any LISP
> specification that an identifier is composed of two parts.
>

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 2 Dec 2011 07:54:25 -0800

Terry,

> these topologies should be left for IETF WGs focused on these technologies).

With respect to chartering LISP WG to work on the LISP "base protocol
changes required to enable VPN", if these changes have to do with
enabling L2 VPNs, then such work should be done in L2VPN WG. If
these changes have to do with enabling L3 VPN, then such work should
be done in L3VPN WG. In both of these cases the outcome of this work
could be reviewed by the LISP WG.

The same should apply to work on enaling "mobile topoligies".

With this in mind I propose to replace the above sentence with the
following:

  The LISP WG is chartered to work on the LISP base protocol and any items
  which directly impact LISP and are related to using LISP for improving 
  Internet routing scalability. 

Yakov.

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

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 2 Dec 2011 11:38:31 -0500

Is there (or could there be) a link outside web page that could
contain auxiliary material, such as research papers,
that may be produced as the work progresses ?

Regards
Marshall

---

From: Albert Cabellos <[email-masked]>
Date: Sat, 3 Dec 2011 16:46:09 +0100

In my humble opinion we should discuss what is the charter of this WG,  
if someone in another WG uses/extends LISP for VPN or mobility is his/ 
her choice.  This should not prevent that this WG could also work on  
such applications, if there are enough volunteers.

Further, and as Terry points out, LISP is experimental and hence, any  
L2/L3 VPN extensions will (most likely) end up being also experimental.

Given that I support the initial wording:

“The LISP WG is chartered to work on the LISP base protocol and any  
item which directly impact LISP including any base protocol changes  
required to enable VPN and mobile topologies (precise operational  
definitions of these topologies should be left for IETF WGs focused on  
these technologies).”

Albert

---

From: Terry Manderson <[email-masked]>
Date: Sun, 4 Dec 2011 16:13:44 -0800

Yakov,

> could be reviewed by the LISP WG.

I understand your point, however that doesn't seem to align with current
IETF practice. I am perfectly comfortable to see the definition of
operational aspects and any other work done which doesn't change the base
spec handled by other work groups that specialize in such areas (VPN or
mobility). This is what I discussed with the ADs. If a change is required in
the LISP fields, packet structure, mapping system or other substrate defined
here to enable those WGs to take up such work items - then those changes
should occur here.

This modus operandi is the same as having IDR fix the AS0 definition, or
allow BGP to carry larger payloads, for BGPSEC instead of having SIDR do it
- and potentially getting it wrong.

>   Internet routing scalability.

How about:

The LISP WG is chartered to work on the LISP base protocol and any items
which directly impact LISP protocol structures or are related to using LISP
for improving Internet routing scalability.

Cheers
Terry

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 5 Dec 2011 11:30:50 -0800

Terry,

> here to enable those WGs to take up such work items - then those changes

Ok.

How about:

   The LISP WG is chartered to work on the LISP base protocol and any
   items which directly impact LISP protocol structures and are related
   to using LISP for improving Internet routing scalability.
  
   In addition, if work done by 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.

The second paragraph is to reflect the point you made above, namely:

                       I am perfectly comfortable to see the definition of

Yakov.

---

From: Terry Manderson <[email-masked]>
Date: Mon, 5 Dec 2011 15:47:32 -0800

Yakov,

> The second paragraph is to reflect the point you made above, namely:

Fine with me.

The current draft now stands as:

 

manageability and
operability of LISP.

Goals and Milestones

---

From: Terry Manderson <[email-masked]>
Date: Mon, 5 Dec 2011 15:57:11 -0800

Obviously the discussion has been on-going.

I have posted a latest draft.

I think that draft sets a fair balance between LISP, and esuring LISP is
interoperable when/if other technologies are added to it, and the other ietf
work groups that have expertise in such areas.

Something that I am interested in getting the WG's opinion on is the school
of thought that since the IAB routing workshop (RFC 4984) the growth of the
routing system has been near predicable and linear in trend. I'm not siding
with any particular viewpoint yet, except to highlight that at some stage
the IAB could revise its stance if it finds itself in agreement with that
observation. This may have impact on the LISP charter.

Cheers
Terry

On 4/12/11 1:46 AM, "Albert Cabellos" <[email-masked]> wrote:

> In my humble opinion we should discuss what is the charter of this WG, if
> someone in another WG uses/extends LISP for VPN or mobility is his/her choice.
> This should not prevent that this WG could also work on such applications, if
> there are enough volunteers.
> Further, and as Terry points out, LISP is experimental and hence, any L2/L3
> VPN extensions will (most likely) end up being also experimental.
> ³The LISP WG is chartered to work on the LISP base protocol and any item which
> directly impact LISP including any base protocol changes required to enable
> VPN and mobile topologies (precise operational definitions of these topologies
> should be left for IETF WGs focused on these technologies).²
> Albert
>

---

From: Terry Manderson <[email-masked]>
Date: Mon, 5 Dec 2011 16:04:56 -0800

Hi Marshal,

Previous charter discussions suggested that it wasn't necessary to include
an outside webpage for 'further' reading, I tend to agree as outside pages
(thus not tools based) tend to date really quickly if not actively
maintained.

That said, if there is a page that does cover _all_ [1] that auxiliary
material in one place I'd be happy to look, review, and reconsider by
reopening the WG discussion.

[1] implementations, research papers, experimental work, additional works
etc.

Terry