Re: [RRG] LISP next steps

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

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

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.


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

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.

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

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



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