Subject: Re: [RRG] NIRA:Combining the hier. interdomain and the OSPF-intradomain netwo...

From: [email-masked]
Date: Wed, 21 Nov 2007 13:28:58 EST

Hello Robin,
I have been writing to this mailinglist because it addresses the most  
interesting and most important topic.( In the past I cared about MPLS and stuff  
like that. MPLS seemed to be a synonym for TE. Today I am more convinced of  pure 
IP forwarding and respective TE. But this is still below the urgency of  what 
is addressed by the IAB raw report.)
I always preferred the RRG-mailinglist as opposed to the RAM-mailinglist  
because I think, that LISP etc. are closer to accomplishment and should  
therefore be dealt with inside RAM. Neither am I in the position to stop LISP  nor is 
it my intention. Just the opposite: With the rejected NIRA project and no  
further proposal submission opportunity for the next years on this area, I  
should be glad if all are concentrated on the loc/ID split protocols in the  
meantime.
 
Constructive criticism: I cannot provide such, e.g. for CONS, if I am  
convinced that all of it is not needed at all.
Anectodal accounts: I do not precisely know what you mean, but for one  
point: Rekthers law. Such hilighted!
But completely ignored. No controversal  discussion about it! Not what  it 
might mean, not how is it understood by all. 
 
I did provide a lengthy description of my NIRA concept a week ago. It was  
much better than what we submitted to the EU.  I know for sure that it will  
work, but I have to presume that the geographical coordinates of the packet  
destination can be provided by DNS as an additional information, and that this  
information can be written as an optional parameter into the IP header. But if I 
 see how often AOL-software or Windows-software upgrades are urged to be  
installed, I hope that this can be done, too.
 
Heiner

In einer eMail vom 21.11.2007 16:09:44 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hello  Heiner,

In the last three or so months you have written 26 messages to  this
list.  I think none of them have contained constructive criticism  of
other peoples' proposals.  In general you have asserted that  there
is a new way of solving the routing scaling problem.  So far,  I
think you have only supplied poorly organised anecdotal accounts  of
some aspects of what you are thinking about.

I believe that in  order to contribute to the work of the Routing
Research Group you need to  do one or both of:

1 - Constructively criticise other proposals - which  means you
provide detailed critiques, hopefully with  suggestions on
how the identified problems might be  resolved.

2 - Provide a reasonably detailed proposal, in a coherent  fashion.
Some folks almost insist every proposal be an  Internet Draft,
but I don't.  For instance I think  Brian's Carpenter's recent
proposal (in a PDF) and Bill  Herrin's TRRP site are perfectly
good ways to develop  ideas.  The proposal needs to be written
in clear enough  detail that people can readily understand the
inner workings  and the major challenges to developing and
deploying the new  architecture.  I think it is good to list the
goals of  the proposal, and the "non-goals" - things you are
not trying  to achieve, but which other proposals in this field
might be  tackling.

I don't think it is good enough to describe only the  intermediate
mechanisms and outcomes of your proposed new routing  architecture -
which is what I think your messages to date may amount  to.  I think
you also need to explain in clear, concrete, practical,  terms how
individual routers or other network elements must behave in order  to
create these mechanisms and outcomes.

I do not think it is  necessary for every proposal to apparently
solve every conceivable  problem.  Such a requirement would stifle
the brainstorming process of  tossing new ideas around.

Please provide a unified description of your  proposal, with
concrete, low-level, network element behaviour descriptions  - and
identify those aspects of your proposal you haven't yet worked  out,
with the reasons why you think they may be practical.

-  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: Robin Whittle <[email-masked]>
Date: Thu, 22 Nov 2007 15:01:33 +1100

Hello Heiner,

The short version of this message is:

  Your proposal requires host and router changes - so it is not
  a solution to the current problems.  If you create a comprehensive
  description of it, with low-level  router behavior specifications
  and detailed examples, I will check it out.

You wrote, in part:

> LISP nor is it my intention. Just the opposite: With the rejected
> NIRA project and no further proposal submission opportunity for 
> the next years on this area, I should be glad if all are 
> concentrated on the loc/ID split protocols in the meantime.

That is what I am working on.

> Constructive criticism: I cannot provide such, e.g. for CONS, if 
> I am convinced that all of it is not needed at all.

This seems to contradict your previous sentence, unless you are
happy for us all to work on something you are convinced is not needed.

> Anectodal accounts: I do not precisely know what you mean,

...

> I did provide a lengthy description of my NIRA concept a week 
> ago. 

Your description:

  http://psg.com/lists/rrg/2007/msg00523.html

had no mention of how routers were to behave in order to achieve the
objectives you described.  I think this is a short, incomplete,
description of even your objectives, with over-reliance on a postal
analogy.  By the way, I think the postal redirection analogy is a
very powerful one for explaining ITR-ETR schemes - in particular the
scaling problems of every Post Office sorting office having the full
database and performing a lookup on every destination address.  I
use it myself.

> It was much better than what we submitted to the EU.

I am not surprised that, as you wrote on 7 November, your submission
was "rated to be POOR and therefore rejected."

> I know for sure that it will work,

Many new architectures might "work".  The question is, which one
would work best - for a given deployment timeframe and a given set
of restrictions regarding incremental deployability.  In the next
next 5 to 10 years, I think this means no host changes and as few
router changes as possible.  (This statement will probably always be
true - I don't know how any scheme, no matter how promising, could
prompt enough people to make the serious investment of host changes,
new routers etc. if the benefits only accrue 5 or more years later.)

> but I have to presume that the
> geographical coordinates of the packet destination can be 
> provided by DNS as an additional information, and that this 
> information can be written as an optional parameter into the IP 
> header. But if I see how often AOL-software or Windows-software 
> upgrades are urged to be installed, I hope that this can be done,
> too.

I do not share your or Tony's optimism about how much we can rely on
host upgrades.  I discussed my concerns yesterday:

  http://psg.com/lists/rrg/2007/msg00559.html

You can't rely on new things in the IPv4 header unless you require
every router in the world to be upgraded to suit your new system -
because changing the IP header requires complete router upgrades and
using an option header causes many, most or all current DFZ routers
to process the packet very slowly.

Bill Herrin had a promising scheme which relied on option headers:

  http://bill.herrin.us/network/trrp-via02.html

but such use of option headers turns out to be unworkable, as was
discovered by Brian Carpenter 13 years ago with his AEIOU proposal:

  http://psg.com/lists/rrg/2007/msg00350.html

Since your proposal is a long-term one, involving host changes, and
new protocols - a new IP header or new option header - with major
upgrades or replacements to all routers, I will not devote much
attention to it.  If you create a comprehensive description of it,
with low-level router behavior specifications and detailed examples,
I will check it out.

 - Robin