Re: SDRP working group

Noel Chiappa <jnc@ginger.lcs.mit.edu> Tue, 17 November 1992 23:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03449; 17 Nov 92 18:06 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03445; 17 Nov 92 18:06 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa16903; 17 Nov 92 18:06 EST
Received: by PIZZA.BBN.COM id aa19409; 17 Nov 92 18:06 EST
Received: from pizza by PIZZA.BBN.COM id aa18510; 17 Nov 92 16:50 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa18506; 17 Nov 92 16:46 EST
Received: from GINGER.LCS.MIT.EDU by BBN.COM id aa04994; 17 Nov 92 16:45 EST
Received: by ginger.lcs.mit.edu id AA07796; Tue, 17 Nov 92 16:45:30 -0500
Date: Tue, 17 Nov 1992 16:45:30 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9211172145.AA07796@ginger.lcs.mit.edu>
To: B.Kumar@cs.ucl.ac.uk, tli@cisco.com
Subject: Re: SDRP working group
Cc: bgp@ans.net, idpr-wg@bbn.com, idrp-ip@merit.edu, jnc@ginger.lcs.mit.edu, unified@caldera.usc.edu

   > 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. 

That's exactly correct. I characterized it as looking like a simple
version of PIP.

   > 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 might differ with some minor details of the above; clearly we have
routing protocols which don't do 1, at least explicitly (e.g. RIP, which
just exchanges routing table entries), and also 3 is not really part of
the IP architecture as well, although we are getting more formal about
something like this. Still, you're basically going in the right line for
a reasonable definition, I think.

   > 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?.

I made exactly the same point to Deborah Estrin over the phone some
days ago and she agreed that soemthing like SDFP would have been a
more accurate name for this particular protocol.

    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.

Looking under the street lights again, I see. This is a bit of a cop-out;
you've left the *hard* part to the end again. In this respect, I find Yakov's
claim (at the NSF Regional meeting in Ann Arbor) that Unified is done is more
than a little disingenuous. Something called SDRP may be done, but the
complete system is a long way from it.

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

Aw, come on, Tony, I didn't expect this sort of stuff from you. This protocol
has next to nothing to do with the functionality that we have come to expect
from something calling itself a "Routing Protocol".  You're right, it is just
semantics, but there are a lot of people serving jail time for things that
are just "semantics" (e.g. for fraud). Semantics *are* important; it's hard
to make the case that this title was not deliberately misleading.

	Noel