SDRP working group

Tony Li <> Tue, 17 November 1992 19:58 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa02544; 17 Nov 92 14:58 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02540; 17 Nov 92 14:58 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa12578; 17 Nov 92 14:58 EST
Received: by PIZZA.BBN.COM id aa17252; 17 Nov 92 14:56 EST
Received: from pizza by PIZZA.BBN.COM id aa16331; 17 Nov 92 13:24 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa16327; 17 Nov 92 13:19 EST
Received: from by BBN.COM id aa22518; 17 Nov 92 13:18 EST
Received: by; Tue, 17 Nov 92 10:17:48 -0800
Date: Tue, 17 Nov 92 10:17:48 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tony Li <>
Message-Id: <>
In-Reply-To:'s message of Tue, 17 Nov 92 13:02:58 +0000 <>
Subject: SDRP working group

   Please correct me if I am wrong.

   Based on the current description of SDRP, that I have with me,
   it looks like more like packet forwarding protocol rather than
   a routing protocol. 

This is very true.  The current draft includes the packet forwarding
mechanisms, the base control messages, and the interoperation with the
moral equivalent of static routes. 

   A routing protocol, in my opinion, must have

   1) a mechanism to gather topology information.
   2) some mechanism to compute routes based on above information.
   (May apply policies etc at this step for inter-domain protocols.)
   3) A well established packet forwarding mechanism that makes use
   of the information derived in step 2.

   I do not see any part in SDRP that does step 1 and 2. If it is going
   to forward on source routes computed by IDRP then, should it not  be 
   more appropriately Source Demand Forwarding Protocol for IDRP?.

If you look a bit farther (see the SDRP charter), you will find that
we do have further information gathering facilities planned for the
protocol.  Route computation is, at this point, a very open research
problem.  Note that these enhancements are in some sense detached from
the current spec, as the functionality in the current spec dos not
rely on these enhancements.

   SDRP, in its current specification, is definitely not a
   self-sustainable inter-domain *routing* protocol. By
   self-sustainable, I mean that it should be possible for a site to
   run *only* SDRP, and still be able to communicate with the rest of
   the world. If it is not self sustainable- then, IMHO, it is not a
   routing protocol but a source forwarding extension to IDRP.

Is this anything other than a semantic quibble over the definition of
a "routing protocol"?