a few commetns in response to Yakovs note of 4/6
Tony Li <tli@cisco.com> Fri, 10 April 1992 07:10 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00325;
10 Apr 92 3:10 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00907;
10 Apr 92 3:13 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa00903;
10 Apr 92 3:13 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa16810;
10 Apr 92 2:23 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa16806; 10 Apr 92 2:22 EDT
Received: from lager.cisco.com by BBN.COM id aa06176; 10 Apr 92 2:25 EDT
Received: by lager.cisco.com; Thu, 9 Apr 92 23:25:14 -0700
Date: Thu, 9 Apr 92 23:25:14 -0700
From: Tony Li <tli@cisco.com>
Message-Id: <9204100625.AA10418@lager.cisco.com>
To: estrin@usc.edu
Cc: idpr-wg@bbn.com
In-Reply-To: Deborah Estrin's message of Thu,
9 Apr 92 22:11:34 PDT <9204100511.AA18831@caldera.usc.edu>
Subject: a few commetns in response to Yakovs note of 4/6
... but it is more importnat (fun) to talk about the things we dont agree on :} And in that spirit... 2. your complaint about idpr being inefficient for small number of data messages is also true for TCP....if your point is that there should be an option to heave explicit source route instead of insisiting on setup, then i expect if you just say that everyone would agree!!! That does not mean that you never want to do setup and that it is not worth experimenting with a first version of a setup protocol Yet existing IDPR documents deprecate non-circuit switched based source routing. There seems to be no experimental evidence or rationale to back this up, yet much of the complexity of IDPR is based on this decision. 5. IDPR does NOT assume a particulakr charging model. The archiecture leaves room for charging model info to be distributed in updates when standard syntax and semantics is defined for various charging models, then this can be taken into account in route computaton. I thnk the same is true for IDRP I think that the lack of extensibility in IDPR policy support is one of its greatest shortcomings. To add a new policy component, we must redefine policy terms and upgrade all routers. But more about this at the unified meeting... 9. Obviously I agree with the notion that ultimately we dont run IDPR as the only interdomain routing protocol. But I dont see why that means we stop experimenting with IDPR as our current prototype of ak source demand routing protocol. Then by the time we go to impleent and finalize design of SDR compontnt of unified, we learn from that experience. Unfortunately, by making IDPR an experimental standard, you invite requests for implementations and deployment (yes, I get them already) in production networks. While I would _encourage_ experimentation, I feel that the standards track will inevitably lead towards deployment of an immature protocol. This is a hinderance due to its opportunity cost for the entire community. One must also wonder how IDPR operates in conjunction with other interdomain routing protocols. To be quite frank, I see no obvious mechanism to get this to work consistently. There is BGP and IDRP and i see the justificatoin being similar altho of course the urgency for BGP to replace EGP was the primary compelling issue there and so it is a poor analogy that Yakov eill undoubtedly point out :} As will I. ;-) Tony
- a few commetns in response to Yakovs note of 4/6 Deborah Estrin
- a few commetns in response to Yakovs note of 4/6 Tony Li
- a few commetns in response to Yakovs note of 4/6 Bob Hinden
- Re: a few commetns in response to Yakovs note of … Deborah Estrin
- Re: a few commetns in response to Yakovs note of … Deborah Estrin