Re: [RRG] Concerns about the RRG process ... & how not to design an airliner

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

Hi Bill and Team,

What you are proposing here:

> We need a comprehensive set of questions that are reasonable across
> the entire solution tree so that we can do an apples-to-apples
> comparison of the various proposals. They all solve the same core
> problem (the current BGP-based DFZ is insufficiently scalable) and
> they all have to run on equipment that we can cost-effectively build
> so there should be a reasonable set of universal questions.

seems to resemble the only significant alternative I could imagine
to the current process: rather than developing a design spec, to
conduct a debate leading to some carefully considered questions and
answers which provide an informative and reasonably balanced
assessment of the key characteristics of each of the map-encap
proposals.  If there are other proposals, which are not map-encap,
but solve a significantly different subset of the routing
scalability problem than the map-encap proposals aim to, then
perhaps there needs to be a separate panel of questions and
assessments for them too.

When I wrote my initial message, I assumed that the current plan of
producing an architectural specification, ready for IETF WG
development, was part of the charter.  So I thought that doing
something different, such as recommending an actual proposal, or
developing some kind of analysis document to help the IESG decide
what to do next, would be outside the charter.

However, the charter says:

  http://www.irtf.org/charter?gtype=rg&group=rrg

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

     An eventual goal is to produce a recommendation to the IETF on
     a new routing and addressing architecture that would be
     appropriate for Internet-scale deployment.

So I think this means we are not bound to develop an actual detailed
specification, according to my understanding of Tony's plan:

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

I think the charter allows the RRG to produce a recommendation such
as: "The map-encap scheme X is the most promising proposal available
at present.  We recommend this be the basis for further development,
but caution that these aspects A, B and C do not seem satisfactory
at present.  We think that improvements along the lines of M, N and
O would significantly improve the proposal."

Scott wrote:

  >> We need a comprehensive set of questions that are reasonable
  >> across the entire solution tree so that we can do an
  >> apples-to-apples comparison of the various proposals.
  >
  > Lixia and I hope to have a first pass done at the end of the
  > week.  It will take a lot of discussion.

so that sounds like a move in this direction.


> To be worth replacing BGP, we'll have to support some system-wide peak
> number of maps and some system-wide peak update rate. The minimums for
> those numbers are the same regardless of our approach. They're a value
> question versus BGP and today's BGP is exactly the same regardless of
> our approaches.

I agree.

> To avoid Randy Bush's $10M routers, there is some peak number of FIB
> entries and some peak update rate that a single device within the
> system can be expected to handle. These maximums are constrained by
> the hardware regardless of our approach.

Yes.  My idea of a full database ITR for millions or billions of
micronets is that its FIB has the entries it needs for current
traffic, with the rest of the mapped space being flagged in the FIB
as "we need mapping for this address if we get a packet addressed to
it".  The unmapped packet needs to be buffered, and the FIB section
of the router (acting as a caching ITR) needs to query the full
database section of the ITR, which is like a full database query
server.  Whether the full database query server is in the same
router or is in a nearby rack, one or two Ethernet cables away,
probably won't alter the performance and reliability of this system.

A map-encap approach which can spread the load over multiple ITRs is
at an advantage regarding these maximums of micronet numbers and
traffic volumes.  With Ivip, each ITR can advertise a subset of the
total set of MABs (Mapped Address Blocks which typically contain
hundreds of thousands or perhaps millions of micronets).  Pushed to
ridiculous extremes to accommodate large traffic volumes and/or
large numbers of micronets, a single ITR could handle a single MAB.
 If that wasn't enough, the MAB could be split into longer prefixes
- each to be handled by a different ITR.

So with Ivip I would say there isn't a hard limit on the traffic
volumes or number of micronets which can be handled by any "ITR", as
long as we recognise that an "ITR" could be a nest of ITRs splitting
the load.  Also these load sharing ITRs could be in different places
but serving roughly the same catchment area.  This applies both to
ITRs inside a network or to OITRDs - Open ITRs in the DFZ.

Probably the same thing could be done with LISP if the designers
thought in these terms - both for ordinary LISP ITRs in networks and
for Proxy Tunnel Routers.

I am not so sure about APT's ability to load share - and you Herrin
Development people are so busy with airliners that you haven't yet
written up your map-encap scheme in sufficient detail for me to say
much about the scaling capabilities of TRRP's ITRs.

> On the other hand, we should avoid questions like "What's the peak
> permissible update rate system-wide?" That assumes a link between
> individual device's capability and the system-wide update rate when
> such a link only exists for some of the approaches we've imagined.

OK - this is a concise way of saying what I wrote above.

My wife Tina and I are really keen to fly in one of your airliners.
 We are led to believe the disco floor is a massive toughened safety
glass window on the Earth below, with a matching arrangement in the
ceiling for the Heavens above.   Are you planning a swimming pool
version?

  Cheers

    - 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