Re: [RRG] LISP next steps

[Robin Whittle <rw@firstpr.com.au>]

Hi David,

Thanks for your reply, in which you wrote:

> My understanding/summary of what I heard this week
> (Tuesday, IIRC) is that the RRG will *not* recommend any
> of the proposed solutions (or any other?) but rather will
> recommend "concepts". What exactly constitutes a
> "concept" wasn't clear (at least to me), even though it
> was briefly discussed. 

OK - I haven't yet listened to the earlier part of the Tuesday
meeting, or the Friday meeting.

I guess the RRG would recommend development of a set of technical
concepts which would (ideally) fit together to create the complete
solution, or perhaps recommend some parts of the solution for
engineering development while leaving other parts up for further
research and discussion.

I guess the RRG wouldn't recommend "develop the proposals in this
set of IDs", but would carefully describe the key principles and
characteristics of whatever needs to be developed.

Ivip is my way of developing a set of approaches which looks best to
me.  Later in the year I plan to produce a reasonably terse
technical description of what this involves, without mentioning Ivip
and whilst trying to leave open questions of terminology.  This will
be part of a future, shorter, version of ivip-arch, which will be a
high-level architectural overview with a list of benefits,
challenges, goals and non-goals.

I am writing the Ivip IDs to help in this RRG brainstorming,
research and decision phase.  These IDs are structured to aid
understanding and hopefully to prompt people to think of new and
better ideas.  They are not ready to be tweaked into Standards Track
RFCs.

I envisage that by the time some of our ideas today wind up in an
IETF WG in mid 2009, they may be combined with other ideas from
outside the RRG's experience - and the whole project would probably
have a different name.


>> Does your BOF announcement mean something like this?
>>
>> 1 - You think LISP is so practical and desirable that it is "the"
>>     routing scalability solution to the exclusion of others - and
>>     perhaps for other purposes.
> 
> The LISP BOF proposal has nothing to do with any other
> proposal.

OK - I understand you think that engineering development in an IETF
WG is the best way to develop LISP, rather than another year
developing as part of the RRG research phase.

My view is that the RRG schedule is good, and that the routing
scalability problem isn't so urgent that we need to rush into
engineering development of any of the proposals.

The scalability problem is partly about BGP convergence and
stability, and partly about many end-users who would like
multihoming being shut out of it due to the difficulties of BGP.
However, in terms of costs of running the DFZ routers, the picture
is neatly summarised by Geoff Huston's graph:

  http://bgp.potaroo.net/

which shows a doubling every 4 years in the single most important
metric of the routing scalability problem - the number of advertised
routes.

I figure the doubling time will drop to 3 years or even 2 as the
pressure to slice up IPv4 space grows, once the fresh pastures have
all been sub-divided around 2011/12.

Meanwhile, anyone who wants to run DFZ routers just plugs more RAM
into their routers, or buys new ones which have the RAM and CPU
capacity to cope with the growth.  To some extent, these router
replacements would occur anyway, due to need for more and faster
ports etc.

My guess is that even if your LISP BOF doesn't lead to a WG this
year, that a map-encap scheme will begin development in a WG by mid
2009, with some RFCs emerging around 2012.  My aim with Ivip is that
people will actively want to deploy it, and will wait for the RFCs
before doing so - rather than having to be cajoled into adopting it.

By then, there will be a much greater fervour for slicing and dicing
IPv4 space more finely without further burdening the BGP control
plane.  LISP, ALT, Ivip or TRRP will all be able to do this.  They
will all be able to support multihoming, portability and TE (though
Ivip's TE capabilities are not explicit).

What is in question is how elegant, cost-effective, flexible,
attractive, and open-ended they are.  In particular, how would each
scheme support mobility or extension so some purpose we haven't
thought of yet?

By then there will probably 500,000 to 600,000 DFZ routes, meaning
that some subset of the routers in the DFZ today will have had to be
upgraded, depending on their CPU power, RAM and the number of
neighbours they have.

I don't think this major architectural change to the Internet is so
urgent that we need to rush things faster than what I envisage -
RFCs in 2012.  At the very best, your accelerated plan for LISP
would have you in a WG in late 2008, rather than mid 2009.

So that is a 9 month head start, meaning - all other things being
equal - that you would have a set of RFCs 9 months ahead of whenever
the RRG process would produce RFCs.   The number of DFZ routes
doubles every 4 years, so with the RRG time-frame, the RFCs would be
ready when the number of DFZ routes was 14% higher than with your
proposed schedule.

Solving the problem before it gets 14% worse doesn't seem like a
good enough reason for pushing one of the current immature map-encap
proposals out of its RRG nest, onto a fast-track of development,
when I think another year in the RRG incubator growing up with its
nestlings would lead to a much stronger adult bird.


I think the RRG process is very productive.  I think it would be
more productive still if people did some critiques of Ivip like I
and others do of LISP, APT and TRRP.


> I'll just note that if someone has a proposal that they
> feel has moved into an engineering phase, the "right
> thing" (IETF process-wise) to do at that point is propose
> a BOF, assuming of course that the authors/proponents of
> that technology want the IETF to standardize that
> technology. 

Sure, this is the right thing to do, given your confidence and sense
of urgency about LISP.


> 	Finally, note that its soley IESG's decision to approve
> 	or disapprove BOFs, and if the outcome of a BOF is that
> 	the participants of the BOF want to form a WG,  that is
> 	also soley the IESG's decision. 
> 
>> 2 - You think the RRG's timetable is too slow 
> 
> Yes.

OK.  On one hand, I can understand your desire to press on and
develop your system into a fully fledged set of RFCs ready for
global adoption.  You have proof-of-concept code running in a number
of sites and you are putting test traffic through it.  I could
imagine not wanting to write more code until you have a more stable
set of RFCs to work from, since if you write code now and later the
WG changes something in detail or in principle, you will have some
potentially very disruptive changes to make to a large body of work.

Also, I imagine you want to have RFCs ASAP so you can plan the
hardware of the next generation of routers.  This is particularly
the case for LISP, since you have the ITRs and ETRs doing such
complex functions.

You can tell from:

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

that I think LISP is nowhere near being an optimal solution to the
routing scaling problem.

I guess you expect to enough people who think LISP is the way
forward that the other proposals - APT, Ivip and TRRP so far -
needn't be considered as serious alternatives.

Or maybe you are expecting to develop LISP in a WG and have one or
more of the others, or whatever the RRG chooses, also developed in
parallel in another WG starting mid 2009.

I don't know enough about the IETF to say how common this is - to
support two WGs working on the same problem in incompatible ways.  I
guess this could happen if there was broad support, say 40 to 50%,
for both proposals, and no prospect of one side merging with or
ceding to the other.  Then the IESG would be faced with choosing one
over the other, or letting both projects develop as best they can,
hopefully learning from each other, with later decisions - including
by end-users - determining which is widely deployed.


However I can't understand your confidence in LISP being ready for
engineering development right now.  I think the problems your
proposal faces include:

  ALT is a global query server system, and so will often be slow
  to get mapping to the ITRs compared to the local query servers
  of APT or Ivip.

  This leaves you with the problem of either expecting end-users
  to adopt the new address space when it suffers from poor
  performance due to delayed initial packets, or coming up with
  some way of speeding up the delivery of the initial packets to
  ETRs, without the ITR having the mapping information.  The only
  way you have of doing this at present is routing them around the
  ALT network - the EMACS multicast idea has to many problems.

  This is assuming that you solve the problem of ALT's strong
  aggregation leading to structures which take no account of
  geography and lead to packets crossing oceans and continents
  between one ALT router and the next, as they ascend the
  hierarchy to a router which covers the destination, and then
  descend the hierarchy towards that destination.

  Christian Vogt (message 259) also argues that this aggregation
  implies provider dependence.

  I think there are a bunch of problems we haven't fully explored
  regarding ALT's use of the ETRs as the authoritative source
  of mapping.  This is a highly decentralised system - making it
  hard to enforce good authentication of who is announcing mapping
  for what EID prefixes.

  You haven't articulated a plan for PMTU and fragmentation problems
  which makes good sense to me or Fred Templin - and no-one has
  written to the list in support of your current plan.

  There are things I consider dead-wood in your proposal - which
  don't need to be there - LISP-NAT and "gleaning".

  By choosing a pure pull system, without any "Notify" (immediate
  push to ITRs which need the changed mapping info), you constrain
  the latency of mapping distribution to be bounded by how short
  the ETRs make the caching time of their replies.  This means an
  ETR could run the mapping pretty hot, with a 20 second caching
  time, but this would place a huge burden of computation and
  query traffic on the ITRs and the ALT network as well as on the
  ETR and any other authoritative ETRs - in proportion to how many
  ITRs were actually handling packets addressed to this EID prefix.

  You specifically disclaim the use of the map-encap system for
  direct support of mobility, but I think you misunderstand how
  map-encap can and arguably should support mobility.  You seem to
  assume that the ITR should tunnel packets direct to the mobile
  node.  But the mobile node will often be behind NAT, so could
  never be reached and treated like an ITR.  I am convinced that
  mobility needs to be handled along the lines I propose:  mobile
  nodes make tunnels to nearby "Translating Tunnel Routers" - like
  choosing one or more nearby home agents.  This is a second
  level of the 3 layer model, the first being whatever mobility
  stuff happens in the access network, such as handover between
  base-stations, which preserves the mobile node's care of address.
  Then, the map-encap system has its mapping changed to tunnel
  packets to the TTRs.  This is the third level, which enables
  optimal paths from non-upgraded correspondent hosts (or from
  the TTRs of mobile correspondent hosts).  The three levels
  make perfect sense and produce a powerful new form of mobility
  which is compatible with all existing hosts - which can never
  be the case with traditional mobile IPv4 or IPv6.

  I think the reason you reject the routing system's involvement
  in mobility - including the use of the map-encap scheme, which
  is a much lighter weight, less costly, more flexible, faster,
  more scalable, scheme than BGP - is that you assume that
  mobility means a mapping change for every change of access
  network.  Yet with the 3 level model I propose, it only needs
  to change when the mobile node needs a new TTR, which will
  typically only be if it moves 1000km or more.  Many people
  don't move that distance month-to-month, or from one year to
  the next.  So for most users, mobility doesn't mean frequent
  mapping changes.  Their mobility requirements will be met by
  the access networks existing mechanisms (level 1) and the
  way the mobile node builds tunnels to its chosen TTR (level 2).

  The map-encap scheme typically won't be seeing frequent mapping
  changes due to mobility for most users, but it is an absolutely
  crucial part of the system, because it enables optimal paths
  from all correspondent hosts to whichever nearby (<1000km) TTR
  the mobile node is currently building its 2 way tunnels to.

  LISP precludes the fast (less than a minute) mapping changes
  which would be so valuable for mobility, while assuming it
  can't be done because mobility would involve mapping changes
  every few minutes.  I argue that it is practical and desirable
  to get mapping to all ITRs in around 5 seconds, and that the
  rate of updates for mobility will generally be very low - since
  most people don't move 1000km very often.  You haven't critiqued
  these arguments, so perhaps you haven't really understood them.


By your own reckoning, your current mapping distribution proposals -
including ALT, which is what I understand you are focusing on - are
too poorly developed to be able to accurately characterise their
performance.  In:

   http://www.employees.org/~swb/draft-brim-lisp-analysis-00.txt

you wrote:

  Some potentially interesting mapping mechanisms have been proposed
  but are still very incomplete.  Therefore this document primarily
  discusses the base LISP protocol, and then discusses possibilities
  with some of the mapping mechanisms but does not try to be a
  complete survey.


Maybe you are confident of greatly improving the situation by the
time of the BOF.   Maybe you are planning a scheme by which the ALT
network's often circuitous path problem can be largely resolved.
Then, I think you would need to run some pretty complex simulations,
based on realistic ideas of where the various ALT routers would be
located, the degree of aggregation per hierarchical step etc. to be
able to estimate the spread of response times to a realistic sample
of queries.

Scott Brim wrote in defence of the "ALT's long paths" argument in:

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

but this is based on two notions:

  1 - That most traffic is within a region.

  2 - That there will be contiguousness between
      EIDs in one region.

By the second point, I think he means that both ends of a
communication, whether on EID space or RLOC space, will have a high
degree of correlation in their address space.  For instance, if all
of Australia used 203.0.0.0/8, that most traffic in Australia would
be to somewhere in this prefix, so the queries and responses on the
ALT network from ITRs in Australia would typically not suffer from
ALT's global nature, or much from the long geographic distances
between routers at each hierarchical level - thereby avoiding the
worst delays predicted by the critiques.

However, I question these assumptions.  Firstly, traffic is all over
the place - partly due to the international nature of the Web, but
also due to the largely non-geographically based nature of
peer-to-peer, worm and spam traffic.

Secondly, it is my impression that IPv4 addresses are geographically
all over the place.


>> and due to the urgency of the situation you want to move LISP
>> into the IETF WG phase ASAP.
> 
> For the what I understand to be the scope of Routing
> Research Group (the routing system), the issues are well
> documented.  

I don't clearly understand this.

>> http://www.1-4-5.net/~dmm/draft-meyer-lisp-eid-block-00.txt
>> http://inl.info.ucl.ac.be/system/files/draft-mathy-lisp-dht-00.txt
>>
> Some haven't been published by the secretariat yet (like
> the lisp-eid-block draft; in my experience they don't
> publish drafts during the IETF). Others, like the
> multicast draft, aren't quite finished, but will be
> before Dublin.

OK - I was providing the URLs for the benefit of RRG members.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com 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