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