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

From: Terry Manderson <[email-masked]>
Date: Wed, 21 Sep 2011 17:04:48 -0700

Hi Folks,

In Prague there was no strong consensus on modifying the LISP Charter from
what it currently is, perhaps only updating the existing Goals/Milestones.

So no clear decision could be made. What I would like to do is push out a
'idea generating' draft charter that is _almost_ identical to what we have
today. 

You can find the existing charter here:
https://datatracker.ietf.org/wg/lisp/charter/

The draft is below.

So in light of such an approach, Joel and I discussed some work items that
came from what was said at the mic in Prague and to us individually.

They are:

* Finish the deployment document
* Get the two security documents done
* Get an operational document at least started, which should include
cache management and ETR synchronization techniques.
* Either in the second security document, or in complementary documents we
need to evaluate the security threat to cache maintenance, and
evaluate the applicability and coverage we get from a reuse of SIDR
technology.

Is anything not represented here that you believe necessary? and conversely
is there something here that is out of scope in your eyes?

Are there work areas not covered by the draft below which you believe should
be?

Draft Charter
------------

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 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 identifier to locator 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 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 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 as well as the
manageability and operability of LISP.

Cheers
Terry

---

From: Lori Jakab <[email-masked]>
Date: Thu, 22 Sep 2011 09:05:05 +0200

Hi Terry,

El 9/22/2011 2:04 AM, Terry Manderson escribió:
> [...]
> Is anything not represented here that you believe necessary?

I think it would be interesting to include mobility in the charter as 
well. The LISP-MN draft is mature and there are some implementations 
already of that spec.

-Lori

> and conversely

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 22 Sep 2011 12:06:16 +0300

Hi Terry

> Are there work areas not covered by the draft below which you believe should

Are there any interest to look further into to future and discuss what
is needed to have a long term solution of LISP, as discussed in RFC
1955?

   This scheme could be extended to not require globally unique IP
   address.  Effectively the combination of AD-Address and IP-Address is
   the globally unique address.  To use this scheme without globally
   unique IP-Addresses and without changing in the hosts would require a
   NAT mechanism in the border routers.  I think it would be preferable
   to change the hosts to have them do the DNS query and add the AD-
   header.  This could be the basis for the long term solution.

   Another interesting aspect of this scheme is that if we were to relax
   the current architecture where one IP-Address is always in only one
   AD, to allow an IP-Address to be in more than one AD, it would
   provide a solution to the issue of allowing a IP entity to get
   service from more than one service provider.

Patrick

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Sep 2011 10:24:24 -0700

Terry, what I would like to know first and foremost, before adding any specific feature or use-cases to the charter is if they *should* belong in the LISP working group charter versus being owne by another working group. And what the working group thinks about this. I will give some examples to get some clarity and to be more specific.

(1) LISP could be used for many data-center use-cases.
(2) LISP could be used for device mobility.
(3) LISP could be used as a IPv6 coexistence solution while delivering route table reduction and low opex multihoming.
(4) LISP could be used as a VPN solution.
(5) The mapping database could be used for other applications like keeping track of multicast group membership.

So, to enumerate each one:

For (1), does the LISP WG take this on or is there a data-center specific protocol solution working group (ARMD is not that working group because it is a requirement definition working group)?

For (2), the MOBOPTs IRTF research group seem to take interest in LISP-MN. Does it do the initial work and have it spin off a mobility working group, which there are many already. To add, there is a cross-product issue too since LISP-Multicast can run in a LISP-MN implementation and there is a multimob working group already established.

For (3), there are zillions of solutions and places where this occurs over the last decade, I would suggest not spinning another working group for this and have the LISP working group be "address-family" agnostic which would also include MAC addressing as a address-family as well a GPS coordinates.

For (4), again, coupled with (3), LISP can do L2-over-L3, L3-over-L3, as well as the other 2 combinations, does the VPN use-case stay in the LISP working group or is it fragmented to be taken to each L2VPN and L3VPN working groups.

For (5), we do not want to error where everything is put into DNS (because it is the only applicaiton level wide-area/multi-organizational distributed database). In our case the mapping database. And moreoever, if the use-case functionality is distributed to other working groups, will there be design change requests to the mapping database design coming from too many source points.

As you can see, this can get very complex and confusing and could result in design fragmentation and opportunity for competitive proposals. All which turn out to add more inefficiencies to the protocol design process which nearly always results in undeployable compromises.

Dino

On Sep 21, 2011, at 5:04 PM, Terry Manderson wrote:

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

---

From: Terry Manderson <[email-masked]>
Date: Mon, 26 Sep 2011 21:17:02 -0700

Thanks Dino,

I encourage all LISP WG members to reflect on the questions below and voice
an opinion.

To paraphrase what Dino has written, one proposal (and Dino correct me if
I've oversimplified) is that the LISP WG should become a working group that
contains ALL things LISP. So wherever a body of work uses LISP
encapsulation, or LISP mapping it may gravitate to here to maintain LISP
interoperability and (where appropriate) protocol cohesion.

..discuss.

:)

Cheers
Terry

On 23/09/11 3:24 AM, "Dino Farinacci" <[email-masked]> wrote:

> Terry, what I would like to know first and foremost, before adding any
> specific feature or use-cases to the charter is if they *should* belong in the
> LISP working group charter versus being owne by another working group. And
> what the working group thinks about this. I will give some examples to get
> some clarity and to be more specific.
> 
> (3) LISP could be used as a IPv6 coexistence solution while delivering route
> table reduction and low opex multihoming.
> For (1), does the LISP WG take this on or is there a data-center specific
> protocol solution working group (ARMD is not that working group because it is
> a requirement definition working group)?
> 
> For (2), the MOBOPTs IRTF research group seem to take interest in LISP-MN.
> Does it do the initial work and have it spin off a mobility working group,
> which there are many already. To add, there is a cross-product issue too since
> LISP-Multicast can run in a LISP-MN implementation and there is a multimob
> working group already established.
> 
> For (3), there are zillions of solutions and places where this occurs over the
> last decade, I would suggest not spinning another working group for this and
> have the LISP working group be "address-family" agnostic which would also
> include MAC addressing as a address-family as well a GPS coordinates.
> 
> For (4), again, coupled with (3), LISP can do L2-over-L3, L3-over-L3, as well
> as the other 2 combinations, does the VPN use-case stay in the LISP working
> group or is it fragmented to be taken to each L2VPN and L3VPN working groups.
> 
> For (5), we do not want to error where everything is put into DNS (because it
> is the only applicaiton level wide-area/multi-organizational distributed
> database). In our case the mapping database. And moreoever, if the use-case
> functionality is distributed to other working groups, will there be design
> change requests to the mapping database design coming from too many source
> points.
> 
> As you can see, this can get very complex and confusing and could result in
> design fragmentation and opportunity for competitive proposals. All which turn
> out to add more inefficiencies to the protocol design process which nearly
> always results in undeployable compromises.
> 
> Dino
>

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Mon, 26 Sep 2011 22:02:52 -0700

LISP is a bit unique in that it can enable many applications
concurrently.

If the effort for each application is spun off to different groups, each
thread will evolve independently and with that the cohesion of the
protocol may quickly be lost.

IMO it is important that the WG retains ownership/authority over all
things LISP.

-v

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Terry Manderson
> Sent: Monday, September 26, 2011 9:17 PM
> To: Dino Farinacci (dino)
> Cc: [email-masked]
> Subject: Re: [lisp] LISP (re-)Charter discussion
> 
> Thanks Dino,
> 
> > specific feature or use-cases to the charter is if they *should*
belong
> in the
> > LISP working group charter versus being owne by another working
group.
> And
> > what the working group thinks about this. I will give some examples
to
> get
> > (3) LISP could be used as a IPv6 coexistence solution while
delivering
> route
> > (5) The mapping database could be used for other applications like
> keeping
> > track of multicast group membership.
> >
> > protocol solution working group (ARMD is not that working group
because
> it is
> > For (2), the MOBOPTs IRTF research group seem to take interest in
LISP-
> MN.
> > which there are many already. To add, there is a cross-product issue
too
> since
> > For (3), there are zillions of solutions and places where this
occurs
> over the
> > last decade, I would suggest not spinning another working group for
this
> and
> > For (4), again, coupled with (3), LISP can do L2-over-L3,
L3-over-L3, as
> well
> > group or is it fragmented to be taken to each L2VPN and L3VPN
working
> groups.
> > database). In our case the mapping database. And moreoever, if the
use-
> case
> > As you can see, this can get very complex and confusing and could
result
> in
> > design fragmentation and opportunity for competitive proposals. All
which
> turn
> >> In Prague there was no strong consensus on modifying the LISP
Charter
> from
> >> So no clear decision could be made. What I would like to do is push
out
> a
> >> 'idea generating' draft charter that is _almost_ identical to what
we
> have
> >> So in light of such an approach, Joel and I discussed some work
items
> that
> >> * Either in the second security document, or in complementary
documents
> we
> >> Are there work areas not covered by the draft below which you
believe
> should

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Sep 2011 22:03:14 -0700

> interoperability and (where appropriate) protocol cohesion.

Right, I was not direct about this point but it can be inferred from below. Thanks for clarifying Terry.

Dino

---

From: John Scudder <[email-masked]>
Date: Wed, 28 Sep 2011 12:21:31 -0700

Terry,

I think your list of bullet points is almost right.  I would something that Joel proposed in Quebec City:

* Publish an example cache management specification.

As a reminder, the purpose of this is to provide something that is amenable to analysis to make it possible to meaningfully "evaluate the security threat to cache maintenance" as you say in your last bullet.  

The relevant excerpt from the IETF-81 minutes (http://www.ietf.org/proceedings/81/minutes/lisp.txt) is the "b" part below (Terry's final bullet point covers the "a" part):

-----
Joel Halpern => Let me paraphrase because what I heard sound very

     reasonable. a) In the threats doc, we should put a little more

     attention on this. b) We should put as WG item a new document

     that addresses what is the right answer to this problem is.

Alia Atlas => What the minimum answer to the problem is.

Joel Halpern => OK.
-----

Second, 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).
 
--John

---

From: John Scudder <[email-masked]>
Date: Wed, 28 Sep 2011 12:21:34 -0700

Terry,

It seems inappropriate to me that LISP be the sole WG that works on all things related to LISP.  It's standard IETF procedure for one WG to build on another WG's protocol.  There are many examples of this.  Of course review by the LISP WG of any relevant specs (both prior to and during last call) may be appropriate.  This is also SOP.

--John

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 28 Sep 2011 22:27:53 +0200

All,

I agree here with John .. the way how I read what is being proposed here 
I would call also impractical.

It seems to me that LISP WG just like any other WG should be involved in 
the core LISP work and not in any potential new application which will 
choose to use LISP.

As example if I would like to propose an overlay which uses LISP to 
interconnect set of ALTO servers I would rather work on it in ALTO WG 
not in LISP. LISP WG could be just involved as far as being aware about 
such work.

That practice has worked very well in the past for large number of other 
IETF solutions. L3VPNs or L2VPNs while heavily using BGP are not 
standardized in IDR. They are standardized in their respective WGs. MPLS 
TE has been topic of MPLS WG and not ISIS, OSPF or RSVP WGs which 
extensions are critical part of it.

Best,
R.

> Terry,
>
> It seems inappropriate to me that LISP be the sole WG that works on
> all things related to LISP.  It's standard IETF procedure for one WG
> to build on another WG's protocol.  There are many examples of this.
> Of course review by the LISP WG of any relevant specs (both prior to
> and during last call) may be appropriate.  This is also SOP.
>
> --John
>
>> I encourage all LISP WG members to reflect on the questions below
>> and voice an opinion.
>>
>> To paraphrase what Dino has written, one proposal (and Dino correct
>> me if I've oversimplified) is that the LISP WG should become a
>> working group that contains ALL things LISP. So wherever a body of
>> work uses LISP encapsulation, or LISP mapping it may gravitate to
>> here to maintain LISP interoperability and (where appropriate)
>> protocol cohesion.
>>
>> ..discuss.
>>
>> :)
>>
>> Cheers Terry

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Sep 2011 19:20:11 -0700

Hi Terry,

Regarding the 5th paragraph of the Draft Charter:

> IETF. At this time, these proposals are at an early stage.

This needs to be updated; here is a proposed rewrite:

  "A number of approaches have been published in parallel in the
   IRTF and IETF. In particular, the IRTF Routing Research Group
   (RRG) has published its recommendations [RFC6115] and design
   goals [RFC6227], and has authorized the publication of three
   solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and
   ILNP [ILNP]."

Thanks - Fred
[email-masked]

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Terry Manderson
> Sent: Wednesday, September 21, 2011 5:05 PM
> To: [email-masked]
> Subject: [lisp] LISP (re-)Charter discussion
> 
> Hi Folks,
> 
> Charter from
> documents we
> believe should

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 28 Sep 2011 23:10:57 -0400

Fred, "Authorized" is I think the wrong word to use to describe the 
publication.  Or at least a misleading word.  The IRTF process is such 
that the RG did not actually approve the publication of any of the 
solutions.  The RG Chair sponsored the publication as an output of the 
RG.  IRTF procedures explicitly recognize and allow for multiple 
minority reports from an RG.

I do agree that we should recognize that a number of ideas have been 
published as RFCs.  And we should probably not be too specific about 
what the RG is doing, since that is liable to change.

Yours,
Joel

On 9/28/2011 10:20 PM, Templin, Fred L wrote:
>> All proposals

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Sep 2011 09:22:40 +0200

John,

> As a reminder, the purpose of this is to provide something that is amenable to analysis to make it possible to meaningfully "evaluate the security threat to cache maintenance" as you say in your la…

I generally like to see things in charters that have (at least in the
background) names attached to them.  Are you volunteering?

Eliot

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 Sep 2011 05:16:21 -0700

Hi Joel, 

> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Wednesday, September 28, 2011 8:11 PM
> To: Templin, Fred L
> Cc: Terry Manderson; [email-masked]

OK. How does this look for a rewrite:

    "A number of approaches have been published in parallel in the
     IRTF and IETF. In particular, the IRTF Routing Research Group
     (RRG) has published recommendations [RFC6115] and design goals
     [RFC6227], and has released three solution proposals for
     publication in IRON [RFC6179], hIPv4 [RFC6306] and ILNP [ILNP]."

Thanks - Fred

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Sep 2011 14:31:17 +0200

Robert, I think the question hangs on (1) where will the expertise be? 
Are they in ALTO or LISP or both?  What expertise is needed?  The IETF
has addressed this problem in both dimensions that have been discussed. 
For example, the DHCP and DNSEXT groups are long standing precisely
because the expertise necessary to extend those protocols can really
only be found in those groups.  It DOES require a flexible management
view from within a working group.  If orthodoxy sets in (and we've seen
that before) clever engineers find ways to route around the damage.  I
am *not* here speaking of LISP, mind you.

---

From: Terry Manderson <[email-masked]>
Date: Thu, 29 Sep 2011 17:05:42 -0700

Hi John,

On 29/09/11 5:21 AM, "John Scudder" <[email-masked]> wrote:

> Terry,
> 
> It seems inappropriate to me that LISP be the sole WG that works on all things
> related to LISP. 

I thought my words captured an openness stance, perhaps not.

There is simply no way for LISP WG to mandate that all things LISP be here.
And such a thing would not be healthy long term, and starts down the "not
invented here" path. What I would like to see captured is that the LISP WG
is there for people who wish to do work on LISP in the LISP WG in various
applications.

If a standards developer so chooses to push a work item that uses LISP in
another WG, then that is their choice, and the choice of the target WG.
Similarly, what I don't want to say is that "I'm sorry - LISP encapsulation
of Carrier Pigeon doesn't belong here, see the Carrier Pigeon WG." For
precisely the same reasons you mention.

> It's standard IETF procedure for one WG to build on another
> WG's protocol.  There are many examples of this.  Of course review by the LISP
> WG of any relevant specs (both prior to and during last call) may be
> appropriate.  This is also SOP.
> 

It will be a normal exercise to maintain awareness and communication with
the other WGs when there is such a spec.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Thu, 29 Sep 2011 17:18:23 -0700

Fred,

I'm not keen on specifically listing _any_ RFCs in the charter. It just
doesn't add meaning at this stage of the WG lifecycle, in my opinion.

How about a simpler:

  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.

This provides the reader of the charter with knowledge that there is a body
of work "out there" and points to the RRG as a place to look first. Beyond
that we would probably fall into the trap of listing almost every RFC that
has (had) anything to do with scaling, EID/LOC split, encapsulation .. .. ..
etc.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Thu, 29 Sep 2011 17:33:39 -0700

Taking the workgroup 'hat' off for a moment (I was going to say
'underpants', but that is just a _bad_ mental image :)

I think what Eliot says here holds true.

In respect to LISP there is a level of expertise here. However adopting a
view that we be exclusive to a core is a little premature. Perhaps in time a
LISP-EXT might pop up, perhaps not.

Your observation about preferring ALTO is actually a perfect example of
preference. You might prefer to go to ALTO, others may choose LISP. The
bottom line for me is not seeing a meaningless turf war commence over
standards work. The ultimate win is that the work gets done. Not
specifically which WG it ends up in, as I'm sure that there will be
sufficient review (both volunteered and requested) by many parties from
various WGs and areas.

Cheers
Terry

On 29/09/11 10:31 PM, "Eliot Lear" <[email-masked]> wrote:

>    Robert, I think the question hangs on (1) where will the expertise be?  Are
> they in ALTO or LISP or both?  What expertise is needed?  The IETF has
> addressed this problem in both dimensions that have been discussed.  For
> example, the DHCP and DNSEXT groups are long standing precisely because the
> expertise necessary to extend those protocols can really only be found in
> those groups.  It DOES require a flexible management view from within a
> working group.  If orthodoxy sets in (and we've seen that before) clever
> engineers find ways to route around the damage.  I am not here speaking of
> LISP, mind you.
>

---

From: Terry Manderson <[email-masked]>
Date: Thu, 29 Sep 2011 17:41:33 -0700

Hi Victor,

I think authority and ownership are stretches of the vocabulary.

I am concerned about protocol cohesion, and I'd like the WG to be the
preferred place (i.e "gravitate") for LISP related work. But saying that
LISP is the locus of control for all this LISP might be a tad far :)

I think we should also keep in mind that LISP is heading for Experimental
publication which means any work that uses LISP in the majority at this
point in time will probably/possibly also end up as Experimental given
downref considerations.

Cheers
Terry

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Sep 2011 08:05:23 -0700

Hi Terry, 

> From: Terry Manderson [mailto:[email-masked]] 
> Sent: Thursday, September 29, 2011 5:18 PM
> To: Templin, Fred L; Joel M. Halpern
> Cc: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Sep 2011 08:32:45 -0700

Hi Terry,

> of work "out there" and points to the RRG as a place to look 
> first. 

I would agree if the charter could point to a webpage
that lists the RRG RFC publications, i.e., in the same
way that IETF working group wepages do. But, the only
RRG webpages I have found have outdated and incomplete
information, and do not cite the RFC publications. So,
I would prefer to include the text I proposed, or
something close to it, since the work is so closely
related to LISP.

> Beyond

I don't think this would become a slippery slope.
LISP spun off out of the RRG albeit in a slightly
different manner than did IRON, hIPv4 and ILNP.
But, as of this time (and for the forseeable future
AFAICT) those are the only four solution proposals
to emerge out of the RRG.

Thanks - Fred

---

From: Scott Brim <[email-masked]>
Date: Fri, 30 Sep 2011 12:17:47 -0400

> something close to it, since the work is so closely

IMHO a WG charter is not the place to have a listing of other
drafts/RFCs that are not in scope, even if they are related somehow.
If other pages are outdated, that's where the problem should be fixed.

Scott

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 30 Sep 2011 10:27:08 -0700

If we can't agree what is going into a charter, how we are going to agree where work is going to happen with even a bigger audience to decide.

The focus is all wrong. The focus should be on the work and not the process.

Dino