Re: IDPR as a Proposed Standard

Noel Chiappa <jnc@ginger.lcs.mit.edu> Thu, 16 April 1992 17:17 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02786; 16 Apr 92 13:17 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa15318; 16 Apr 92 13:21 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa15314; 16 Apr 92 13:21 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa13869; 16 Apr 92 13:04 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa13865; 16 Apr 92 13:02 EDT
Received: from GINGER.LCS.MIT.EDU by BBN.COM id aa14907; 16 Apr 92 13:05 EDT
Received: by ginger.lcs.mit.edu id AA11965; Thu, 16 Apr 92 13:04:07 -0400
Date: Thu, 16 Apr 92 13:04:07 -0400
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9204161704.AA11965@ginger.lcs.mit.edu>
To: idpr-wg@bbn.com, yakov@watson.ibm.com
Subject: Re: IDPR as a Proposed Standard
Cc: iab@isi.edu, iesg@nri.reston.va.us, jnc@ginger.lcs.mit.edu

	Yakov, I read your note with interest. In almost all cases, I just
don't think the argument is as one-sided as you make it, and in any case, it's
late to be bringing some of these up. In a number of instances (e.g.  doing
path setup versus per packet source routing), you are now trying to
second-guess basic architectural decisions that were made years ago.
	Realize, I'm not saying you don't usually have good technical points;
what I'm saying is that reasonable people with sufficient knowledge can reach
different conclusions from you about the suitabilty of this protocol going
forward for further use.

	It's true, sometimes those decisions were made without as much data
would have been desireable. However, it's not clear you can fault designers
for pressing forward without all possible information. Sometimes the
information is simply not there, and the designers can either press forward or
get sidetracked into a major research project.
	(For example, the average flow "length" in number of packets, and how
this effects whether or not flow setup is viable; some time ago I reviewed all
existing traffic studies and coudn't find one which gave me this critical
information.) I don't think you can fault designers for going forward without
complete knowledge; good intuition based on limited information is a key skill
of a top-flight designer.

	Another example is this point about the large amount of data required
in IDPR as the Internet gets larger, since it needs a map of the places it
wants to route through before it can do so.
	I happen to agree with you that this is a real problem, and as you
know, I've been thinking about how to handle it for a while. I will go further
and tell you that a key reason I've been uninvolved in IDPR is that I consider
the fact that it didn't tackle the heirarchy problem as crippling in the long
run, and unintereting to me.
	However, none of this means they made the wrong decision. At the time
they made that scope restriction, as a way to get forward progress going, Open
Routing had been creeping for years. The funding agency simply didn't want to
continue with such slow progress. As a result of this restriction, we now have
a complete protocol and implementations.
	Do I wish they hadn't made that hard choice that way? Yes. Am I
sure that they didn't get something of equal or greater value by giving
that up? Maybe not; they've now got something.

	Is it everything I'd like? No. Is it a useful tool that will give us
lots of good experience with non-hop-by-hop routing (note: h-b-h *routing*
is not the same term or concept as h-b-h *forwarding*), flow-setup, etc,
etc. These are important concepts, we need experience with them, and IDPR
is a very good first cut.
	I think you yourself would have to the first to concede that you can
get good results (both understanding and service) out of a routing protocol
even though it has not yet reached the final stage of polish. The early
versions of BGP have been most useful in the Internet.

	Additionally, as I indicated in the opening, it's really unfair to
come in with these things at this point. This is a problem we have in the
IETF all the time, as people who weren't in all the way try and influence
things later on, and rehash the same arguments the original members had, to
the utter dementia of the original members who are trying to get their
design out.
	Again, I'm sure this is an experience you well recall from the
BGP effort, and I'm sure you sympathize with those who are going through the
same process now.

	Again, this is not to say to you don't have good technical points.
You do. In fact, I also have technical disagreements with some of the basic
features of the protocol. That, however, is not the issue.
	To me, the questions are a) was this design done in an open and
thoughtful way, consistent with the ideals of the IETF, and and b) is there
something we can gain, either in understanding or service, by deploying it.
	I am convinced that the answer to both of these is yes, and I thus
think it is reasonable to advance this protocol to PS, on the understanding
that this is not "The Internet routing protocol", but "An Internet Routing
Protocol". In the IETF style, let's try it and see what we learn from it.


	Noel