Subject: [RRG] EXPLISP BOF at the Dublin IETF

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Jun 2008 15:11:42 +0300

All,

As you probably know, sometime ago the LISP team asked for a BOF in the 
Dublin IETF. It was not easy to decide what to do with this request. The 
initial request was for a WG that would produce standards. 
Unfortunately, we are not quite there yet. The technology just is not 
ready, not this particular proposal nor the other ones. We might be 
heading into the right direction with map-n-encap/translate, but before 
standards can be created we need to have a solid understanding of what 
the mapping system should be like, how the old and new Internet can talk 
to each other, and what the effects to the rest of the Internet will be.

That being said, the question turned into whether we could have a group 
that focuses on experimental RFCs. I do value implementation experience 
and ability to test things. Frankly, I think the RRG is doing exactly 
the right thing by focusing on concepts and not protocols, but the other 
side is perhaps too neglected; some discussion of experimentation and 
bottom-up design would also be helpful. Like keeping the coders awake... 
Of course,  the other extreme would also be bad, if we ignored 
conceptual problems as long as we can test something. The right approach 
would be somewhere in the middle. And routing scalability is a hard 
problem that needs face to face time, possibly lots of it. Can we 
provide more time?

On the other hand, why do we need yet another group to look at this? We 
certainly don't want to send a signal that the RRG can be closed, the 
work has moved to IETF. We don't want to send a signal that the protocol 
selection is done, and the answer is Lisp. That would premature. And we 
do not want to have a group that merely ships RFCs, without trying to 
advance our knowledge of the issues relating to the solutions.

With all the above in mind, I have approved a limited scope BOF for 
Dublin. This BOF/WG focuses on LISP and ALT, documents the open issues 
in these designs, suggests ways to conduct tests to resolve those 
issues, and acts as a forum to provide information about results of 
those experiments. My hope is that some of this information can also be 
fed back to the RRG, and helps the overall design decisions. All design 
discussion should continue on the RRG list as-is.

Welcome to the BOF in Dublin! (But I do not yet know what day and time 
it will be.) And as always with BOFs, we expect the community to provide 
input that helps the decision to create or not the eventual WG. Or an 
Exploratory Group in this case -- see RFC 5111 for more details.

Experimentation in LISP BoF (EXPLISP)
=====================================

Name:                Experimentation in LISP BoF (EXPLISP)
Date and time:  (TBD)
Chairs:              Darrel Lewis <[email-masked]>
                     David Conrad <[email-masked]>

AGENDA:
------
 5 min Agenda bashing                                       Chairs
15 min Goals and scope of the BOF, relation to RRG          Arkko
10 min Introduction to LISP and solution space              Farinacci
15 min Open issues in mapping systems                       Fuller
15 min Open issues in interworking                          Lewis
15 min Implications to upper layers                         Thaler
75 min Open discussion on experimentation and WG creation   All

BOF DESCRIPTION
---------------

The IAB arranged a workshop in October, 2006 to focus on routing and
addressing issues [0]. This workshop identified scalability problems
in the global routing system. The research community is working to map
the overall design space and understand the tradeoffs between the
different solutions. This work happens in the Routing Research Group
(RRG). The solutions discovered so far have interesting behaviours
that are not fully understood by mere desk analysis. For instance,
some of the solutions have packet reordering and delay implications
that may affect higher layers. Some have MTU implications for large
parts of the Internet. Most solutions require deployment of new nodes,
and the incentive models for deploying them are not entirely clear.

LISP and the LISP Alternative Topology mapping system (ALT) is one
solution in the overall design space, under the general category of
"map-and-encapsulate" mechanisms. The purpose of this BOF is to form
an Exploratory Group (RFC 5111) at the IETF. The group will host
discussions and documents necessary to perform experiments that help
the community understand how the above behaviors are effected by LISP
and ALT

The expected outputs are:

- document(s) that describe open issues where experimentation
  may be helpful,
- document(s) that describe planned experiments and results thereof,
  and
- experimental protocol specifications (exp, June 2009)

As an Exploratory Group, this group has a finite lifetime of 18
months. At the end of those 18 months, and depending on the outcome
of the experiments and the design work from the RRG, the group
may either be terminated or rechartered. The group shall also:

- clearly label its results as experimental
- avoid design discussions that are within the scope of the RRG,
- refrain from spending significant amount of time on the well
  understood parts of map-and-encapsulate mechanisms
- demonstrate commitment to focus on experiments before
  submitting any protocol specifications for publication
  as RFCs

This group is only focused on LISP and ALT. Some results may apply to
other designs as well, such as solutions involving a similar mapping
system but a different encapsulation scheme. But this is not
guaranteed. If other proposals surface from the research community
with equally interesting questions that would benefit from similar
experimentation, future groups can be created for that purpose, as
long as there appears to be sufficient interest in the community for
such work. The interest is demonstrated via XXX independent
implementation efforts.

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Robin Whittle <[email-masked]>
Date: Sat, 28 Jun 2008 14:40:06 +1000

Hi Jari,

I support the LISP-ALT team having their own discussion list
concentrating on their experimental work, since that does not seem
to fit well with the RRG at present.  Maybe an experimental IETF WG
would be a good way to do it.

I entirely agree with this:

> The technology just is not ready, not this particular proposal nor
> the other ones. We might be heading into the right direction with
> map-n-encap/translate, but before standards can be created we need
> to have a solid understanding of what the mapping system should be
> like, how the old and new Internet can talk to each other, and
> what the effects to the rest of the Internet will be.

I fully support writing code, running prototypes etc.  I wish I had
more time to work on Ivip, with more IDs, writing code etc.

I think the LISP-ALT team could contribute to the solution of the
routing scaling problem better if they also:

1 - Write (to the RRG list - or some other related list which
    does not yet exist) detailed critiques of other proposals
    which differ from LISP, but aim to achieve the same or
    similar goals.  APT and Ivip are well enough documented to
    form the basis of detailed, constructive, critiques - such
    as:

    a - Any fundamental, technical or business-case problems in
        Ivip's fast-push mapping distribution system.

    b - Fundamental problems in how both APT and Ivip push the
        full mapping data to ITRs and Query Servers at some
        chosen point in the network and use fast, reliable,
        pull (and perhaps "notify" local push) to all local
        ITRs.

    c - Implementation details of the above, which differ
        entirely between APT and Ivip.

    d - Ivip's business case for OITRDs and how it contrasts
        with the lack of business case, so far, for LISP PTRs.

    e - APT's assumption of the creation of separate APT
        islands, when it should be possible to avoid this,
        and so remove some problems which the islands create.

2 - Better explain how LISP-ALT system works, by way of
    practical examples, presentation material with graphics
    etc.  I am not the only one who finds it hard to understand
    the LISP IDs clearly, and frequently finds that when a
    question about LISP is answered on the list, that the
    explanation involves things which seem to contradict what
    we thought we learnt from the LISP IDs.

3 - Create a LISP home page so people can find an authoritative
    list of latest IDs, latest explanations, latest news etc.

You wrote:

> Frankly, I think the RRG is doing exactly the right thing by
> focusing on concepts and not protocols, but the other side is
> perhaps too neglected; some discussion of experimentation and

I proposed an RRG-Sandbox list to be run alongside the RRG list, to
discuss such things while leaving the RRG discussion focused as
Lixia and Tony desire.

  http://psg.com/lists/rrg/2008/msg01540.html
  http://psg.com/lists/rrg/2008/msg01595.html

> conceptual problems as long as we can test something. The right
> approach would be somewhere in the middle. And routing scalability
> is a hard problem that needs face to face time, possibly lots of
> it. Can we provide more time?

This is the biggest IT question of the early 21st century.  I doubt
the RRG is going to devise the solution, in complete architectural
detail in 2008-03 sufficient to convince the IETF to embark on a
single path of developing standards track RFCs.

Time will march on - as it is wont to do - until someone devises and
implements a solution, and until a sufficiently large majority of
end-users willingly adopt it.

> On the other hand, why do we need yet another group to look at
> this?

I think we need at least one more group to discuss the routing
scalability problem, because the RRG focus involves rejecting
discussion of actual proposals and of "details" which many of us
regard as crucial.

> We certainly don't want to send a signal that the RRG can be
> closed, the work has moved to IETF.

Indeed.

> We don't want to send a signal that the protocol selection is
> done, and the answer is Lisp. That would premature.

Absolutely.

> And we do not want to have a group that merely ships RFCs, without
> trying to advance our knowledge of the issues relating to the
> solutions.

I don't want to frustrate the efforts of the LISP-ALT people to
advance their work however they wish.  However I think that it would
be better to have a single list, not just one focussed on one aspect
of LISP, where all people interested in this field discussed all the
relevant proposals, and where the designers of each proposal took
greater efforts than I think the LISP-ALT folks have so far to
understand and critique proposals other than their own.

> discussion should continue on the RRG list as-is.

OK - but what about detailed discussion of other proposals?
LISP-NERD, APT, Ivip, TRRP, Six/One Router or any newer nascent
proposals, such as converting IPv6 to GSE addressing:

  http://lists.arin.net/pipermail/arin-ppml/2008-June/010988.html
  http://psg.com/lists/rrg/2008/msg01534.html

I am opposed to the creation of separate forums for each of these,
apart from each group having their own private mailing list, of course.

We really need creative design ideas, constructive criticism of all
the proposals etc. - ideally on one list.  Since the RRG can't
accommodate this, I favour the creation of a second list.  On such a
list, if there was too much arcane stuff about LISP-ALT or any other
proposal for that new list to handle well, then that would be a time
to bud off a more specialised list.

 - Robin

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 28 Jun 2008 12:08:15 -0700

>    we thought we learnt from the LISP IDs.

Here is a slide that has been used in many presentations.

The top side is the initial Data Probe or Map-Request flow sent from  
the 11.0.0.1 ITR soliciting a Map-Reply from the destination site that  
owns EID 240.1.1.1. Then the bottom side is shows that ITR 11.0.0.1  
uses ETR 1.1.1.1 for subsequent packet encapsulation.

The solid purple lines indicate where BGP over GRE operates. And the  
dotted purple lines are GRE tunnels where BGP is not used so we can  
realize a low OpEx ITR/ETR.

We have the pilot network up running LISP+ALT for both IPv4 and IPv6  
EID-prefixes. We use 240.0.0.0/4 and 2610:00d0::/32 as EID-prefixes  
for IPv4 and IPv6 respectively.

Dino

P.S. RRG, if this is an inappropriate post, I'm sorry, I won't do it  
again.

---

From: Robin Whittle <[email-masked]>
Date: Sun, 29 Jun 2008 12:46:04 +1000

Hi Dino,

Thanks for this explanation and slide - but there was just one slide
image file in your message, while you mentioned two.

If you can post the second slide to the list or to me I will add
them, or link to them in the list archives, with your explanation,
to: http://www.firstpr.com.au/ip/ivip/lisp-links/ until such time as
you have them on a LISP homepage.

You wrote:

> P.S. RRG, if this is an inappropriate post, I'm sorry, I won't do it again.

It doesn't seem right to have to think twice about discussing
technical matters on a mailing list which is devoted to solving the
most significant IT challenge of recent times.

  - Robin

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 28 Jun 2008 20:33:55 -0700

> image file in your message, while you mentioned two.

I didn't mention two slides. I intended one slide. I was referring to  
the "top side" of the one slide versus the "bottom side" of the one  
slide. The top side shows the packet flow when the mapping doesn't  
exist and the bottom side shows the packet flow when the mapping does  
exist.

Dino

---

From: Robin Whittle <[email-masked]>
Date: Sun, 29 Jun 2008 18:33:08 +1000

Hi Dino,

Sorry, I didn't look closely enough at what you wrote or the
diagram.  I planned to look at it properly later, and have now done so.

I added the image to http://www.firstpr.com.au/ip/ivip/lisp-links/
with a link to this discussion.

> The top side shows the packet flow when the mapping doesn't exist
> and the bottom side shows the packet flow when the  mapping does
> exist.

OK. It is hard to show everything on a diagram, but a key point is
the distinction between packets travelling natively on the Net and
those travelling on the ALT network (LAT).

The map request packet, which is perhaps an encapsulated initial
data packet, travels along the GRE tunnel to the nearest ALT router.
 There, over the GRE links to other ALT routers, each ALT router
forwards the packet according to its destination address 240.1.1.1.
 The structure of this LAT network results in the packet arriving at
the correct ETR for this destination host.  The map reply message
goes back via the ordinary Internet (no GRE tunnels or ALT routers)
to the ITR.  Subsequent encapsulated data packets go from the ITR to
the ETR via the ordinary Internet too.

Its not clear to me how the 12.0.0.1 ITR has a tunnel to an ALT
router, unless the dotted line "Low Opex" indicates a tunnel,
without the need for a physical link to this ALT router.

The diagram makes it look easy, with a single GRE hop between the
first and the final ALT router.  However, in reality, it would be
common for the packet to have to ascend the highly aggregated ALT
hierarchy before it could descend the hierarchy towards the ALT
router with a direct link to the correct ETR.  Also, each GRE tunnel
may involve traversing multiple physical routers.  This long path
problem was discussed:

  http://psg.com/lists/rrg/2008/msg00229.html

with a diagram:

  http://www.antd.nist.gov/~ksriram/strong_aggregation.png

and a round-up of the debate:

  http://www.firstpr.com.au/ip/ivip/lisp-links/#long_paths

  - Robin

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 29 Jun 2008 02:35:59 -0700

> data packet, travels along the GRE tunnel to the nearest ALT router.

There are Data Probes or Map-Request packets. A Data Probe is a data  
packet that gets LISP encapsulated where the inner destination address  
is copied to the outer destination address.

A Map-Request is a UDP packet where the destination address is the  
destination EID and the source address is the locator of the  
encapsulating ITR.

> forwards the packet according to its destination address 240.1.1.1.

Right.

> the ETR via the ordinary Internet too.

Right.

> without the need for a physical link to this ALT router.

The 12.0.0.1 ITR is a low-opex router and it has a configured GRE  
tunnel to the ALT router.

> first and the final ALT router.  However, in reality, it would be

And in reality it is that easy.  ;-)

> hierarchy before it could descend the hierarchy towards the ALT

The ITR has a default 0.0.0.0/0 EID-prefix route so it knows to  
forward all Data Probes or Map-Requests over the tunnel.

> may involve traversing multiple physical routers.  This long path

Yes, and so what? The logical topology can be relatively congruent to  
the physical topology but because it is logical we want to reap the  
benefits of it being logical so we can aggregate EID-prefixes as best  
we can.

The ALT topology could be a topology where we use addressing based on  
Geo location, but more importantly it is based on address allocation  
rather the topological allocation.

Dino

---

From: David Meyer <[email-masked]>
Date: Sun, 29 Jun 2008 20:08:59 -0700

>> forwards the packet according to its destination address 240.1.1.1.

	While a minor point, its probably worth noting that you
	can BGP peer to the ALT over any interface type you like,
	so long as both sized can put the interface they are
	using into the VRF (default or otherwise) that is being
	used for the ALT. For example, the existing LISP+ALT
	network runs over GRE tunnels, as well as both native and
	dot1q ethernet interfaces (where that is more convenient;
	for example when the interface is one side of a cross
	connect).  

	Dave

---

From: David Meyer <[email-masked]>
Date: Sun, 29 Jun 2008 20:09:56 -0700

> 	so long as both sized can put the interface they are

s/sized/sides/

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Jun 2008 05:59:43 -0700

Dino,

Your slide indicates a re-classification of the 240/4 space
as public IPv4 addresses, but I don't necessarily agree that
that is the best use of the space. At most, that would give
a short-term scaling for IPv4 but it has already been said
here that scalable deployment of IPv6 is the goal.

Instead, the 240/4 addresses could make life much better for
private addressing within end sites and enterprises, while
EIDs go to public IPv6 addresses. The question is whether
2^32 (or thereabouts) end sites/enterprises is enough
(seems like it should be)?

Fred
[email-masked]    

>-----Original Message-----
>From: Dino Farinacci [mailto:[email-masked]] 
>Sent: Saturday, June 28, 2008 12:08 PM
>To: Robin Whittle
>Cc: RRG; Jari Arkko
>Subject: Re: [RRG] EXPLISP BOF at the Dublin IETF
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 30 Jun 2008 07:39:16 -0700

> here that scalable deployment of IPv6 is the goal.

The slide is an example how LISP+ALT works. It does not decree any  
request or mandate for  address allocation.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Jun 2008 09:12:36 -0700

Dino, 

>Sent: Monday, June 30, 2008 7:39 AM
>To: Templin, Fred L
>Cc: Robin Whittle; RRG; Jari Arkko

Could you perhaps use a different example IPv4 prefix then?

Thanks - Fred