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
- Re: SDRP working group B.Kumar
- SDRP working group Tony Li
- Re: SDRP working group Noel Chiappa
- Re: SDRP working group Noel Chiappa
- SDRP working group Tony Li
- SDRP working group Tony Li
- Re: SDRP working group Deborah Estrin
- Re: SDRP working group lee