Re: Evolution and the routing architecture

From: Kastenholz, Frank (FKastenholz@unispherenetworks.com)
Date: Mon Apr 08 2002 - 08:28:39 EDT


At 08:47 AM 4/5/02 -0500, RJ Atkinson wrote:

>>Several people have mentioned that restricting the requirements to
something
>>that is purely evolutionary just won't do, and have criticized the Group B
>>requirements for requiring an evolutionary approach. I.e. they are
critical
>>of the requirement to evolve from today's network to tomorrow's network
and
>>argue that a revolutionary approach is necessary.
>
> I must have missed the notes you mention.
>
> I have seen several folks (me included) suggest that an
evolutionary
>approach was not the kind of thing that belonged in the iRtf, but
>instead that evolutionary work more nearly belongs in the iEtf.
>This is very much different than the summary above, because this speaks
>to *where* a given approach should be undertaken, not which is or
>isn't the right answer for the global Internet at a particular point
>in time.
>
> For my own part, I think both approaches should be persued,
>though it seems mighty odd to be trying to undertake both in a single
>Routing Research Group. Maybe the right approach is to split into
>2 separate RGs, with different leadership (NB: such a decision could only
>be made by the IRTF Chair).
>
> I'm not speaking for the IAB, but my understanding was that
>the IAB thought that evolutionary work would be handled within the
>usual IETF processes and that the role of the IRTF RRG was to undertake
>a more revolutionary ("clean sheet of paper") approach.
>
> Perhaps the RRG Chairs can clarify where which of us are confused
>on scope and charter ?

My view, and I believe it is also Sean's view, is that the
research group is supposed to be a place where various
groups of people do a lot of thinking, talking, writing
of documents, and so on. In so far as interdomain routing
is concerned, the group is free to produce multiple
proposals. We (Sean and I) do not want to limit the RRG
to producing a single proposal for solving "the routing
problem" because that then leads into all kinds of
procedural ugliness -- basically we turn into the IETF.

That said, it would be nice if we did produce a single
proposal for "solving the routing problem" because that
means that if/when that proposal reaches the IETF, more
people will be behind it to try and get it accepted
as-is... But we don't want to _force_ the RRG to come
up with a single proposal -- the RRG should produce
proposals and ideas and new lines of thought, not
standards...

F

=======================================
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.



This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT