Subject: [RRG] LISP next steps

From: David Meyer <[email-masked]>
Date: Fri, 14 Mar 2008 12:58:35 -0700

Folks,

	As I mentioned on the rrg chat room this morning, we are
	planning a LISP BoF for the Dublin IETF. The proposed
	agenda is included below (also http://www.1-4-5.net/~dmm/lisp.bof). 

	Please let us know if there are other things we should be
	covering.

	Thanks, 

	Dave

----

LISP BoF (LISP)
===============
Name:                LISP BoF (LISP)
Area:                Internet/Routing
Conflicts:           TBD
Expected attendance: 200
Special requests:    none
Number of Slots:     one
Timeslot:            2 hours and 30 minutes
Chairs:              Vince Fuller and Darrel Lewis

AGENDA:
------
 5 min Agenda bashing                            Fuller
10 min Introduction and Problem Statement        Fuller
20 min Goals and purpose of the BOF              Lewis
20 min LISP Proposal	 		         Farinacci
25 min LISP Deployment and Implementation Status Farinacci/Iannone
15 min LISP+ALT status				 Fuller
15 min LISP Interworking Draft			 Lewis
10 min Business Models				 Brim
30 min Open Discussion                           All

BOF DESCRIPTION
---------------
LISP and the LISP Alternative Topology mapping system (ALT) are
proposals that respond to the problems discussed at the IAB's 
October, 2006 Routing and Addressing Workshop [0]. Since both
the base LISP protocol and the ALT mapping system are  in the
engineering and deployment phase, the purpose of this BOF is to
form a working group whose charter (see below) will be to complete
any remaining engineering work on the LISP base protocol [1] and
the LISP+ALT system [2], as well as any functionality required
for LISP Interworking [4]. Finally, the working group will also
track the status of LISP implementations (such as [3]) as
well as investigation of alternate mapping systems (including [5]).  

Description of Proposed Working Group
-------------------------------------
LISP (Locator/ID Separation Protocol)

Last Modified: 2008-03-13

Chair(s):
 TBD

Internet Area Director(s):
 Jari Arkko <[email-masked]>
 Mark Townsley <[email-masked]>

Routing Area Advisor:
 TBD

Secretary(ies):
 TBD
 
Mailing Lists:
 General Discussion: [email-masked] (note: not up yet)
 To Subscribe: https://www1.ietf.org/mailman/listinfo/lisp
 Archive: http://www1.ietf.org/mail-archive/web/lisp/current/index.html

Description of Working Group:
 See BOF description above.

Goals and Milestones:

Mar 2009  Submit base LISP specification to the IESG for
          Proposed Standard.

Mar 2009  Submit base ALT specification to the IESG for
          Proposed Standard.

Mar 2009  Submit the LISP Interworking specification to the IESG
	  for Proposed Standard.

Jul 2009  Re-charter or close.

Internet-Drafts:
	draft-brim-lisp-analysis-00.txt
	draft-farinacci-lisp-06.txt
	draft-farinacci-lisp-multicast-00.txt
	draft-fuller-lisp-alt-01.txt
	draft-iannone-openlisp-implementation-00.txt
	draft-lewis-lisp-interworking-00.txt
	draft-mathy-lisp-dht-00.txt
	draft-meyer-lisp-eid-block-00.txt

Request For Comments:
	  None

References
----------
[0]     Meyer, D. et. al., "Report from the IAB Workshop on
        Routing and Addressing", RFC 4984.

[1]     Farinacci, D. et. al., "Locator/ID Separation Protocol
        (LISP)", draft-farinacci-lisp-06.txt.

[2]	Fuller, V., et. al., "LISP Alternative Topology
	(LISP-ALT)", draft-fuller-lisp-alt-01.txt

[3]	Iannone, L., and O. Bonaventure, "OpenLISP Implementation
	Report", draft-iannone-openlisp-implementation-00.txt.

[4]	Lewis, D., et. al., "Interworking LISP with IPv4 and
	IPv6", draft-lewis-lisp-interworking-00.txt.

[5]	Mathy, L., et. al., "LISP-DHT: Towards a DHT to map
	identifiers onto locators", draft-mathy-lisp-dht-00.txt.

---

From: Robin Whittle <[email-masked]>
Date: Sat, 15 Mar 2008 17:41:10 +1100

Hi David,

I haven't yet listened to Friday's meeting, so perhaps some of my
questions would be answered by that.

My understanding of the RRG's role and planned timeline is based on:

  http://www.irtf.org/charter?gtype=rg&group=rrg
  http://psg.com/lists/rrg/2007/msg00686.html  (2007-12-02)

    The Routing Research Group (RRG) is chartered to explore
    routing and addressing problems that are important to the
    development of the Internet but are not yet mature enough
    for engineering work within the IETF.

    The group will produce a list of prioritized design goals
    and a recommendation for a routing and addressing architecture.

    - floor stays open for new innovative solutions

    - at the same time we encourage efforts on identifying
      fundamental commonalities and differences among proposals,
      and design tradeoffs.

    - starting from March'08 we will drive the group effort towards
      convergence

    - we hope to reach a final recommendation by March '09.

So I understand that the RRG aims to form rough consensus for a
recommendation to the IESG in March 2009 about what approaches
should be recommended to the IESG for engineering development in an
IETF WG.

That could be zero, one or more distinct proposals, perhaps various
sub-units of a complete solution, maybe two conflicting proposals or
something else.  I guess the preferred option is to achieve rough
consensus on a single cohesive proposal or set of modular proposals
which are regarded as both better than the alternatives and
promising enough to use as the basis for development and deployment.

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.

2 - You think the RRG's timetable is too slow and due to the urgency
    of the situation you want to move LISP into the IETF WG phase
    ASAP.

In the absence of further information, it is easy for me to get
these impressions.

Also, I don't assume that all people who have written IDs regarding
LISP are part of a tight-knit team, so I don't know how much your
BOF proposal reflects the intentions of all these people.  I note
that your announcement includes a list of the LISP IDs you
presumably consider to be relevant, but that this does not include
draft-lear-lisp-nerd.

Your announcement lists a new ID "draft-farinacci-lisp-multicast"
which hasn't been mentioned on the RRG list yet, and which can't be
found at the IETF site or via Google.  Some other new ones which
likewise can't be found like this are:

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

  - Robin

--
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: Dino Farinacci <[email-masked]>
Date: Sat, 15 Mar 2008 09:12:54 -0700

> likewise can't be found like this are:

It hasn't been published yet. Will probably be published in April.

Dino

---

From: David Meyer <[email-masked]>
Date: Sat, 15 Mar 2008 10:38:37 -0700

Robin,

> promising enough to use as the basis for development and deployment.

	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. 

>     perhaps for other purposes.

	The LISP BOF proposal has nothing to do with any other
	proposal.

	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. 

	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.

> 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.  

> 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.

	Dave

---

From: Robin Whittle <[email-masked]>
Date: Sun, 16 Mar 2008 13:18:09 +1100

Hi David,

> "concept" wasn't clear (at least to me), even though it

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.

> The LISP BOF proposal has nothing to do with any other

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.

> that technology want the IETF to standardize that

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

>> 2 - You think the RRG's timetable is too slow 

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.

> Research Group (the routing system), the issues are well

I don't clearly understand this.

> multicast draft, aren't quite finished, but will be

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

  - Robin

---

From: David Meyer <[email-masked]>
Date: Sat, 15 Mar 2008 20:34:43 -0700

Hey Robin,

> Thanks for your reply, in which you wrote:

	Sure.

> engineering development while leaving other parts up for further

	I think I understand what you're saying, Check me on
	this: So the RRG should recommend a sort of
	meta-recommendation, i.e., that the IETF should develop
	"a set of technical concepts" that others (the IESG?)
	would use to what, evaluate proposed working group
	charters for WGs that do the protocol development for
	some proposal that fits the "set of technical concepts"?
	Is that close?   

	BTW, if so (I'm at least close), who do you envision
	developing this set of technical concepts? For example,
	would we need a working group for that? 
	
> characteristics of whatever needs to be developed.

	Do you envision these principles as being at the level
	like "It is recommended that the IETF develop protocols
	based on Locator/ID split", or more fine-grained like "It is
	recommend that the IETF develop protocols based on
	address rewriting"? Or something even more fine-grained? 

	Also, do you envision that a recommendation could be
	something unrelated to what the RRG has been focusing on,
	say, like "It is recommended that the IETF develop
	protocols based on the NIMROD architecture"?

> engineering development of any of the proposals.

	Understood. BTW, I'd be glad a talk on at the next RRG on
	the kinds of lessons we've learned through engineering
	LISP enough to actually implement it. These include
	architectural, design, and implementation lessons, as
	well as insight into how folks might want to deploy a
	given solution, how they view the OPEX and performance
	tradeoffs, etc. In any event, I'm glad to do it if folks
	think such a talk would be interesting and in-scope for
	the RRG. 

> 2009, with some RFCs emerging around 2012.  

	2012? That is 6 years after the IAB workshop in AMS, and
	almost 20 years (depending on how you count) since the
	events that resulted in the IPNg process. That said,
	implementations, if they don't start before the specs
	reach RFC status, will require something like another two
	more years to develop hardware, plus whatever it takes to do
	software development, dev testing, field testing, ...Now
	you're talking something (conservatively) like 2015-2018.
	
	I don't know about you, but that seems like a very long
	time. 

> would have you in a WG in late 2008, rather than mid 2009.

	We wanted to be ready to send to documents to the IESG by
	Mar 2009. As far as chartering a WG, if we do a BOF in
	Dublin, and the IESG took the issue of a LISP WG up in
	their next telechat (likely in April), then in theory a
	WG could be chartered by say, early May, 2008. That would
	seem to be the tightest practical lower bound on getting
	a WG chartered. More likely you'd need a few months to
	bash the charter around with the IESG sponsor (at least
	that's been my experience every time I've done it), so
	maybe July or August. So it seems late 2008 is a good
	guess.  

> I don't clearly understand this.

	What I was trying to say is that it is my sense that the
	issues/problems with the current routing system/architecture
	are well documented, for example in the report from the
	IAB workshop, or in the RADIR problem statement, or any
	number of presentations from Vince Fuller or Geoff Huston
	at the NOGs.

	Dave

---

From: "Tony Li" <[email-masked]>
Date: Sat, 15 Mar 2008 21:47:57 -0700

Hi guys,

|> > 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 think I understand what you're saying, Check me on
|	this: So the RRG should recommend a sort of
|	meta-recommendation, i.e., that the IETF should develop
|	"a set of technical concepts" that others (the IESG?)
|	would use to what, evaluate proposed working group
|	charters for WGs that do the protocol development for
|	some proposal that fits the "set of technical concepts"?
|	Is that close?   

Close, but one level off.  Again, we are chartered to deliver an
architecture.  Not do protocol development work.  Our job is to look at the
full broad solution space and attempt to narrow it down, starting from the
top and understand the full spectrum that is available.  Then to look at the
different segments within the solution space and continue to whittle those
down until we can partition the solution into particular functions and
describe the properties of those functions.  Thus, it's up to the RRG to
deliver "a set of technical concepts" that, integrated, form the
architecture.

In essence, we should be staying at a level of abstraction well above the
protocol work, where we are effectively providing a functional specification
of the various protocols, but not fill in the bits and bytes.  We should
stop entirely when we have an adequate definiton of the functionality.

Now, Dino will immediately respond that "the devil is in the details".  ;-)
This is certainly true.  However, this does NOT imply that we necessarily
need to work out all of the details to provide the functional specification.
In particular, where there is some question about the feasibility or
tractability of a particular approach, we should certainly be willing to go
off and perform some experiments (possibly even coding) to determine
tractability.  That does NOT mean that we need to fully flesh out a
prototype of all parts of our recommendation.

|	Do you envision these principles as being at the level
|	like "It is recommended that the IETF develop protocols
|	based on Locator/ID split", or more fine-grained like "It is
|	recommend that the IETF develop protocols based on
|	address rewriting"? Or something even more fine-grained? 

It should definitely get more fine-grained.  Again, it should be specific
enough, with enough rationale so that a set of WG's in the IETF can simply
sit down with it as their problem statement and quickly and directly sit
down to the task of protocol design.  They shouldn't have to ask how the big
pieces fit together or what it is that their particular function should do.
Again, please refer to the list of properties that we put together this week
for the mapping function.  We should be able to characterize all of these
down to some reasonable extent.

Exactly how much detail is necessary?  To borrow some legalese, someone
"skilled in the art" should have no problem sitting down and cranking out
something that just works, assuming that they do a reasonable job meeting
the specific recommendations and functional requirements.  At the same time,
the implementor shouldn't feel overly constrained.  Again, folks who are
practiced in writing software functional specifications should have a fair
understanding of the feel of this level of detail.

|	Also, do you envision that a recommendation could be
|	something unrelated to what the RRG has been focusing on,
|	say, like "It is recommended that the IETF develop
|	protocols based on the NIMROD architecture"?

It's certainly possible that we might turn up a new sector in the solution
space in our discussions.  Handley's proposal, for example, was a segment
that was not previously discussed.  I would not discount that there are
other segments that are unexplored -- we have not made a systematic search
of the solution space.

However, making a recommendation of NIMROD would be precisely what I'm
suggesting that we don't do: refer to a specific proposal.

|> > The LISP BOF proposal has nothing to do with any other
|> > proposal.

Moreover, the BOF proposal is outside of the scope of the RRG and is,
frankly, off topic for the mailing list.  I do realize that there is some
commonality of interest in the audience, but holding the BOF is *not*
forwarding our work within the RRG, and discussing holding the BOF is simply
a level of indirection on a tangential subject.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Sun, 16 Mar 2008 23:08:50 +1100

Hi David,

I won't comment on my guesses about what the RRG would produce,
since Tony has described this in detail in a recent message:

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

> BTW, I'd be glad a talk on at the next RRG on

Yes - a talk would be more interactive for folks at the meeting, and
a written message on the list would be helpful too, with a different
kind of interactivity as people responded on list with further
questions.

> I don't know about you, but that seems like a very long

I don't want things to drag on, but the Net will cope - and I can't
imagine something as momentous as a new routing and addressing
architecture being developed to the RFC stage properly before about
2012.

I envisage Ivip working fine, initially, with all functions
including ITR and ETRs being done in software on servers.  So there
is no hardware development required to get the system running quite
nicely.  That doesn't mean these devices would be optimal for large
traffic volumes - but it will take another few years for those
volumes to develop, by which time the routers will be more able to
do the work themselves.  However, I haven't thought a great deal
about this, so I wouldn't make great claims about this perspective.

I won't comment on the BOF, since Tony wrote that it is off topic.

> number of presentations from Vince Fuller or Geoff Huston

OK.  While opinions vary on how severe the routing scaling problem
is, and therefore what measures should be taken and when, I think
these documents do a reasonable job of describing it.  However, I
wrote critiques of both:

  http://www.ietf.org/mail-archive/web/ram/current/msg01809.html
  http://psg.com/lists/rrg/2007/msg00199.html

in which I made suggestions such as that "portability" be a goal,
rather than a more circuitous term which didn't mention
"portability" when in fact "portable address space" is clearly the
only way of meeting the end-user's requirements.

Since no-one can imagine radical changes to BGP which would solve
the routing scaling problem, the only solution seems to be a new
routing and addressing architecture - probably a map-encap system -
which makes this the biggest deal in Internet engineering for
several decades.

It would be wrong, I think, to just make the new routing and
addressing architecture fix the initially identified problems
without consideration of whatever other important goals can and
should be achieved with such a bold and long-lasting project.  I
think the most obvious additional goals to consider are better
utilization of IPv4 address space and support for mobility.

I have an expansive view of the problem space, which I understand
makes some folks uncomfortable - since they fear it might lead to an
overly ambitious or over-complex solution.

 - Robin

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 16 Mar 2008 10:10:54 -0400

On Mar 15, 2008, at 11:34 PM, David Meyer wrote:

> <snip !>

I don't get this. Are you talking about 2009 ? Or, did you mean to
say the IESG telechat in _August_, with a WG chartered no sooner than
_September_ ?

Regards
Marshall

---

From: David Meyer <[email-masked]>
Date: Sun, 16 Mar 2008 08:44:19 -0700

Marshall,

> say the IESG telechat in _August_, with a WG chartered no sooner than

	Sorry, the latter. It really was a back of the envelope
	guess to respond to Robin, and I missed by 1 IETF. Given
	that, I would think the lower bound timeline would be
	something like: 

	(i).	Do a BOF in Dublin 

	(ii).	The IESG could discuss WG formation at their next
		telechat (after the Dublin IETF). 

		The earliest reasonable time for next IESG
		telechat  *could be* sometime August. I'm
		guessing now, of course; the next telechat could
		also easily be pushed into September (or later),
		as you point out. The IESG could also decide not
		to take up the issue, so its all really just a
		guess. 

	(iii).	So add a few more months for charter bashing, and
		you get something like "late 2008". 
	
	The point was that it looks like the soonest one could
	reasonablly expect to get a WG chartered, starting today,
	would be "late 2008". 

	Dave

---

From: David Meyer <[email-masked]>
Date: Sun, 16 Mar 2008 08:48:45 -0700

> a level of indirection on a tangential subject.

	Understood. Just trying to keep things as open and
	transparent as the I{E,R}TF processes will allow. 

	Dave

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 16 Mar 2008 10:19:02 -0700

> 	you're talking something (conservatively) like 2015-2018.

And let's be realistic here, implementation experience *always*  
results in spec changes. I have never seen it otherwise.

That is, if the there is any traction to a proposal. There are cases  
of no spec changes for things no one had implemented, but that means  
the technology is irrelevant.

Dino

---

From: Vince Fuller <[email-masked]>
Date: Sun, 16 Mar 2008 16:41:42 -0700

> a level of indirection on a tangential subject.

I'll note that all discussion of Routing and Addressing scaling issues, for
which the "[email-masked]" list was originally created, were redirected to the
"[email-masked]" list some months ago. 

Since there would appear to be much to discuss in this space and that a great
deal of that discussion has now been deemed out-of-scope for the RRG, perhaps
it is time to re-active the "[email-masked]" list and take the general topic
of R&A scalling back there.

	--Vince

---

From: "Tony Li" <[email-masked]>
Date: Sun, 16 Mar 2008 22:14:00 -0700

|Since there would appear to be much to discuss in this space 
|and that a great
|deal of that discussion has now been deemed out-of-scope for 
|the RRG...

Aren't you over-reacting just a bit?

The only thing that is out-of-scope is the discussion about arranging a LISP
BOF.

Tony

---

From: Randall Atkinson <[email-masked]>
Date: Mon, 17 Mar 2008 06:01:52 -0700

% Since there would appear to be much to discuss in this space and that a great
% deal of that discussion has now been deemed out-of-scope for the RRG, perhaps
% it is time to re-active the "[email-masked]" list and take the general topic
% of R&A scalling back there.

That sounds sensible, with the obvious extension that discussion of specific
Routing RG topics/proposals should remain on the Routing RG list, while
things on R&A scaling outside scope of Routing RG likely belong on either
the RAM list (or some specific other list -- HIP RG for HIP stuff as an example).

Ran

---

From: Vince Fuller <[email-masked]>
Date: Mon, 17 Mar 2008 09:37:21 -0700

> The only thing that is out-of-scope is the discussion about arranging a LISP

Well, that, plus all content regaring engineering, operations, prototype
deployment, and experimental results (i.e. anything having real-world
applicability and solving real problems) has been deemed out-of-scope for
presentations at RRG meetings. 

To me, at least, that would tend to imply that discussions of same are
out-of-scope for this list.

For the record, the LISP authors were not attempting to start a discussion
about a LISP BOF. What we were doing was soliciting interest and ideas for
said BOF from what we thought was the appropriate community of interest. We
ask that any follow-ups on that subject be directed to the LISP interest
mailing list: [email-masked].

	--Vince

---

From: Vince Fuller <[email-masked]>
Date: Mon, 17 Mar 2008 09:44:31 -0700

> mailing list: [email-masked].

My apology for prolonging this thread, but I need to correct the typo above
(propagated from an incorrect annoucement when the list was created) the
mailing list is [email-masked].

	--Vince

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Mar 2008 00:32:46 +0200

By the way, just to clarify where we are on this: The ADs have received
the BOF request and will be making decisions on this and other IETF-72
BOFs in due time. That is, the status of the BOF is "under consideration".

For what it is worth, I think the routing scalability problem is hard,
and deserves enough time on the agenda so that it can be thoroughly
discussed. But a perhaps more relevant question is exactly how that time
is best used. I don't want to claim any particular model works best; I
see a lot of value in working with concepts. But equally, there are also
things that are best discovered through protocol design, implementation,
measurement, and testing. The crux is not focusing entirely on one side
of this, and being able to figure out what are the right issues that we
need to do conceptual or experimental work on. (In fact, I think it
would be useful if the RRG talked about what the unknowns in the current
designs are, so that we could talk about which of those would benefit
from more detailed protocol or experimental work. This would also be
good input for the ADs to base their BOF decisions on. Or the RRG to
grant more time for topics similar to those in the BOF request.)

Also, obviously, everyone, please continue the discussion on the topics
that we talked about in the meeting and the list. And continue your
implementation and test efforts; all of this is going to be needed in
order to have a workable and best possible solution for our problem.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Mar 2008 01:10:41 +0200

And per request, I would like to clarify that I do not think we are
ready for standards in this space yet -- not by a long shot. Too many
open questions. But I think experimenting with some of these designs
maybe helpful to answer some of the hard questions, and eventually help
us pick an architecture and protocols that can be standardized -- likely
significantly revised ones from the experiments phase.

Jari