Re: SDRP working group

lee@erg.sri.com Wed, 18 November 1992 18:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03933; 18 Nov 92 13:44 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03929; 18 Nov 92 13:44 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa17413; 18 Nov 92 13:44 EST
Received: by PIZZA.BBN.COM id aa26241; 18 Nov 92 13:43 EST
Received: from pizza by PIZZA.BBN.COM id aa25957; 18 Nov 92 13:01 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa25953; 18 Nov 92 12:59 EST
Received: from ginkgo.erg.sri.com by BBN.COM id aa07759; 18 Nov 92 12:58 EST
Received: from localhost by ginkgo.erg.sri.com (5.65/2.7davy) id AA20018; Wed, 18 Nov 92 09:58:48 -0800
Message-Id: <9211181758.AA20018@ginkgo.erg.sri.com>
To: bgp@ans.net, idpr-wg@bbn.com, idrp-ip@merit.edu, jnc@ginger.lcs.mit.edu, unified@caldera.usc.edu
Subject: Re: SDRP working group
In-Reply-To: Your message of Tue, 17 Nov 92 16:51:29 -0500. <9211172151.AA07839@ginger.lcs.mit.edu>
Date: Wed, 18 Nov 92 09:58:47 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: lee@erg.sri.com

>
>Huh? What on earth lead you to this conclusion? IDPR is a very differemt beast
>(for one thing, it's a real routing protocol) using a different model of how
>to do the source routing (with flow setup), and the prime contractor (BBN) is
>not working on Unified (i.e. SDRP) at all. IDPR work is going forward; my
>understanding is they are getting ready to do a signficant field trial using
>the completed implementastions of the IDPR Routing Protocol.
>
>     Noel

All,

  Not only is IDPR work going forward, but SRI has used the IDPR
  (architecture and code) as a basis for the development of the
  Cooperative Gateway (CG).  The CG is more for a military
  environment--it requires all of what IDPR has too offer plus
  more.  

  We have added enhancements to IDPR including alternate routing
  around domains (in case of domain, node, and link failures), transit
  policies based upon traffic type (we have a new IP option [#141]
  with a traffic type field), and a mechanism whereby a domain
  administrator can define in advance, policies for different
  anticipated condition that will be advertised depending upon the
  network state.  We also have a follow-on effort where we will look
  at additional policies (e.g., source policies and transit policies
  based upon time, perhaps transit policies based upon
  source/destination hosts) and other enhancements (e.g., perhaps
  enhanced alternate routing or local route repair and Dijkstra's
  algorithm).  

  BBN and SRI have been talking to ensure that if the needs between IDPR
  and CG overlap, that we don't duplicate work and will share each
  other's mods/enhancements to IDPR/CG.  For instance with source
  based policies, SRI will implement source policies based upon access
  restrictions and BBN will implement source policies based upon
  requested services (and therefore transit policies based upon
  offered services).

  BBN (speaking for Martha; she can provide you with all the details)
  is planning a pilot installation along with some demos; SRI
  is currently discussing participation in this with their
  (SRI's) client and hopes to be a participant.

Diane