Re: [RRG] Consensus? Users will not adopt solutions which result in "split-system" functionality

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

Hi Randall,

Thanks for your replies.  You wrote:

>   Most of your stated beliefs here about "reality" are inconsistent
> with my own prior experience in Network Engineering for a
> multi-continent ISP,  inconsistent with my prior work on a very
> large all-continents private IP network, and inconsistent with
> my experience in enterprise IP networks.
> 
>   It is perhaps not surprising that since my experience
> is so inconsistent with your assertions, then I don't reach
> the same conclusions that you have reached.

OK.

>   Given the charter at hand, which is for the Routing RG to
> propose an architecture to the IETF rather than to endorse
> some specific engineering proposal, it is not at all surprising
> to me that the Routing RG has followed its charter and has
> not focused on trying to select a specific engineering proposal.

I understand this.  In order to arrive at that architecture some
questions are being asked, such as whether or not to consider
translation schemes.  In order to come to a reliable answer about
that, or any other decision to include or exclude a class of
potential solutions, I think it is necessary to look at at any
detailed proposals in that class.  Other people may think a decision
can be made reliably without considering such low-level details.

In one of my messages I do discuss a translation approach to the
routing scaling problem in a purely theoretical manner (without
reference to Six/One Router) and argue that this class of solution
can only be useful with multiple sets of address space - which is
not feasible with IPv4.


>   More generally, I'd encourage you to try to raise the "altitude"
> of your discussions -- less about specific detailed proposals, less
> about *engineering* tradeoffs (both of which are IETF responsibility,
> not IRTF responsibility), and more focus about the *architectural*
> tradeoffs to hand.

In my view the path to the best design involves a lot of work with
low level details - trying one combination and then another, trying
to find a set which works really well together.  I am not rushing
into implementation, as the LISP folks seem keen to do.

I am considering low-level details such as PMTUD:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

that every map-encap scheme needs to consider.  Fred Templin is the
other person who has tackled this difficult area in meaningful
detail.  So far, the LISP team have only a cursory and I think
inadequate approach to PMTUD, and there is nothing in APT or TRRP
which considers it.

One could design a building in sweeps of aesthetic and broad
functional design, and leave the details to engineers to sort out.

However the best buildings are achieved by simultaneously
considering many lower-level aspects of the design, such as exactly
where the air is going to flow, where the services are going to be
installed and maintained, where the light is going to fall at
various times of the day and year, how noise from the
airconditioning affects those inside and outside the building etc.

I have a proposal to solve the routing scaling problem, and as far
as I know, you don't.  I would really appreciate you and others
criticising my proposal.  While there is a lot more work to do on
it, some key parts of it are described in enough detail for you to
critique it in meaningful detail:

  http://www.firstpr.com.au/ip/ivip/
  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
  http://tools.ietf.org/html/draft-whittle-ivip-arch-01
  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00

Some people prefer to operate from a high altitude.  I try to
consider all levels at once.

  - 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