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
- IDPR as a Proposed Standard yakov
- IDPR as a Proposed Standard Gene Tsudik
- IDPR as a Proposed Standard Tony Li
- IDPR as a Proposed Standard yakov
- Re: IDPR as a Proposed Standard Milo S. Medin (NASA ARC NSI Project Office)
- IDPR as a Proposed Standard yakov
- Re: IDPR as a Proposed Standard Deborah Estrin
- IDPR as a Proposed Standard yakov
- Re: IDPR as a Proposed Standard Noel Chiappa
- IDPR as a Proposed Standard yakov
- Re: IDPR as a Proposed Standard Noel Chiappa
- Re: IDPR as a Proposed Standard Deborah Estrin
- Re: IDPR as a Proposed Standard little
- Re: IDPR as a Proposed Standard vcerf
- Re: IDPR as a Proposed Standard Noel Chiappa
- IDPR as a Proposed Standard yakov
- Re: IDPR as a Proposed Standard Noel Chiappa
- IDPR as a Proposed Standard yakov
- Re: IDPR as a Proposed Standard Noel Chiappa
- IDPR as a Proposed Standard yakov
- Re: IDPR as a Proposed Standard Noel Chiappa