Subject: Re: [rrg] The RRG's capacity to handle detail is not up to the task of design...

From: [email-masked]
Date: Sun, 4 Jul 2010 18:58:41 EDT

See below,
Heiner
 
In einer eMail vom 26.06.2010 06:05:08 Westeuropäische Sommerzeit schreibt  
[email-masked]:

completely disagree with this idea of separating  "architecture"
from "engineering" - especially the idea of leaving  "engineering" to
someone else to solve.

Can you point to any  successful outcomes of this disdain for, or
deferment of interest in,  "engineering"?  In any field whatsoever -
software development, IETF  protocols, ship-building, aircraft design,
commercial buildings, dam, road  or railway construction?

Except when doing the initial brainstorming, a  designer of a new
architecture should be able to show it will work at all  levels of the
design - irrespective of whether some people think of these  levels as
"architecture" or "engineering".

The proposed  architectural enhancements for IPv4 and IPv6 should also
have a clear set  of goals and non-goals, and address the major
challenges of the need for  widespread voluntary adoption.  It should
also go beyond scalable  multihoming to achieve mobility on a massive
scale.

The RRG has not  developed or achieved consensus on a set of goals, or
a problem  statement.  ILNP has no list of goals or non-goals.

I have  attempted to do this with Ivip, and I think I have  generally
succeeded.  But it seems that the result far exceeds the  attention
span or interest of most RRG members to read and comment  about.  Even
my attempt at writing an RRG  Recommendation:

http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

seems to  be too long (19 pages) and detailed for anyone to comment on.

ILNP  is simple and short enough for you and many other RRG people to
read and  comment upon.  However, it is completely inadequate as a
solution to  the routing scaling problem - for reasons I mentioned  in
msg06219. 
 
HH:
Right. It is a bad idea to come up with an architecture which defers the  
proof of functioning to any later engineering. And also: It is a bad thing  
to   focus  only  on one issue (e.g. scalability) at a  time and to disregard 
the many concurrent issues (Multicast, TE,  mobility, dealing with loops,   
 ...). 
 
Also,an architecture should not only be backward compatible but also  
future-compatible.
Prior coming up with some architecture the true causes of the  
misachievements should be identified and discussed. I can understand  the sticking to 
DV, given that the alternative were a flat topology of the  entire internet. 
But this argument is broken. Do the DV-supporters know  what future progress 
they  
are disabling hereby ? Or do they  think,  it causes only some 
inconvenience (table size, churn)  which newer hardware shall/will handle ? I really 
would appreciate hearing  from  the DV-supporters which disadvantages they are 
aware of. With DV you  will never get to knowing  not only the topology but 
also  the  current traffic load. Instead this is cut off for good!

It suits  Ran's preference for remaining a the
"architectural" end of the design  process, his lack of interest in
what he regards as "engineering" details -  and his evident lack of
interest in questions of adoption:

http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

Nor, it seems,  do you or Ran have interest/time to comment on some
critiques of ILNP, such  as what I just wrote about ILNP's approach to
mobility  (msg07031).

Neither you or Ran have written anything to help Fred  Templin refine
his IRON IDs, which I understand you also want to have  published as
IRTF RFCs.

I am not suggesting that you or any  other RRG folks should spend time
on Ivip or IRON or anything else.   We are all volunteers.

However, given the pervasive lack of interest in  any proposal which
involves sufficient complexity to actually work, I don't  think you
should claim the RRG has done its job properly.

Most  active participants have failed to read and meaningfully  discuss
significant contributions such as Ivip, or more recently,  IRON.
There has been considerable RRG discussion of LISP, but the  LISP
folks have generally been uninterested in discussing  these
substantial critiques, either on the RRG list or in the LISP  WG.

I know we are all short of time.  But with Ivip in  general, and with
TTR Mobility, you have had 3 years.   To gain a  good understanding of
the 3 month-old DRTM, you can read 6 pages of text  and peruse three
diagrams.  That would take an hour or less.   This is a fraction of
the effort which you and many other people put into  reading and
writing RRG messages every week, so as the months and years go  by,
being short of time is clearly not the limiting factor.

I think  you, Ran and some other folks are too focused on changing all
hosts to  relieve the Network of some extra workload.  This is a very
pure,  mathematical, approach by which you limit the functionality of
the network  and its routers in order that they can scale very well.
You appear  untroubled by the consequent requirement that hosts to do
extra work and  use new, more complex, protocols.

As a result of your elevation of  network simplicity to the primary
goal, you you quickly dismiss any  Core-Edge Separation architecture
such as LISP, Ivip or IRON.

With  ILNP, you are pursuing an architecture which changes all host
stacks (and  for IPv4 requires upgrades to all DFZ and other routers),
because it suits  your conviction that the Network can't or shouldn't
be called upon to be  made more complex and do extra work, to support
current host protocols in  the quest for scalable multihoming and
mobility.

Four days ago I  argued:

"Overloading" of Loc & ID functions is good for  hosts and should be
maintained
http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

that the  current host protocols and the division of labor between
routing system and  hosts have profound advantages.  I have mentioned
this frequently in  the past.  Yet no-one has commented.

ILNP will probably never be  adopted even slightly by genuine users in
IPv6, where it has some technical  elegance - due to:

1 - The need for host stack  changes.

2 - Substantial benefits for adopters and for scalable  routing only
being delivered once almost every host  and network adopts it.

3 - Being unsuitable for  mobility.

4 - Burdening all hosts with extra packets or longer  packets.

5 - Introducing extra delays in the establishment of  communication
sessions.

ILNP has absolutely  zero chance of helping with the IPv4 scaling /
multihoming / mobility  problem for these reasons and because it
requires longer packets (with the  IPv4 Option) and upgrades to all
DFZ and other routers in order to handle  this Option.
Right, Robin. That's why we non-ILNPers can be very relaxed. Sad enough for 
 IPv6 that it would need ILNP
to become ...I don't know what to say.

These problems with any CEE (Loc/ID Separation) approach  have been
obvious since before this recent 3 year phase of the RRG's work  -
which is why people developed LISP, Ivip, IRON and TIDR.

So I  think that in recommending ILNP, you are completely mistaken.

Hopefully  in the future there will be a group of people with time and
interest to  discuss and contribute to architectures which are
complete enough (and  therefore more complex than ILNP and more
carefully designed than LISP) to  actually achieve all the goals of
scalability, multihoming, mobility and  widespread adoption by
voluntary means alone.
I am neither  afraid of LISP nor ILNP wrt eventual  progresses because it 
is wrong to believe that
only the "one chosen solution" will do. Just the contrary: For about 10  
years all is provided to enable RFC 2547-VPNs. Well, you can use the hereby  
developed technique (which is based on vendor-specific information  elements) 
  to build an overlay  instead for private traffic  ( VPN ) rather for 
public traffic, i.e. to detect singular clusters of the  new architecture (TARA, 
lvip, XYZ) and to interconnect them with whichever sort  of tunnels. Like 
all those VPNs can co-exist, the new architectures can  co-exists as well.
The best one will succeed, and not the first one. Hence, this race last  
January for becoming CHOSEN just costs me a tired smile.

At future years I intend to write up Ivip and DRTM more  thoroughly
and hopefully write some code for a test network.  Until  then, please
see:

http://www.ietf.org/mail-archive/web/rrg/current/msg06823.html

in  response to Tom Petch (msg06831) regarding his suggestion I write
RFCs for  the CES/CEE distinction and for DRTM.

-  Robin

_______________________________________________