[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 rw@firstpr.com.au:
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 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