SDRP working group
Tony Li <tli@cisco.com> Wed, 18 November 1992 02:54 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04281; 17 Nov 92 21:54 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04277; 17 Nov 92 21:54 EST
Received: from PIZZA.BBN.COM by CNRI.Reston.VA.US id aa20703; 17 Nov 92 21:53 EST
Received: from pizza by PIZZA.BBN.COM id aa20796; 17 Nov 92 21:47 EST
Received: from BBN.COM by PIZZA.BBN.COM id aa20792; 17 Nov 92 21:46 EST
Received: from lager.cisco.com by BBN.COM id aa14372; 17 Nov 92 21:46 EST
Received: by lager.cisco.com; Tue, 17 Nov 92 18:45:54 -0800
Date: Tue, 17 Nov 1992 18:45:54 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tony Li <tli@cisco.com>
Message-Id: <9211180245.AA00735@lager.cisco.com>
To: jnc@ginger.lcs.mit.edu
Cc: B.Kumar@cs.ucl.ac.uk, tli@cisco.com, iwg@ans.net, idpr-wg@bbn.com, idrp-ip@merit.edu, jnc@ginger.lcs.mit.edu, unified@caldera.usc.edu
In-Reply-To: Noel Chiappa's message of Tue, 17 Nov 92 16:45:30 -0500 <9211172145.AA07796@ginger.lcs.mit.edu>
Subject: SDRP working group
[This is just the same response that I gave Noel in the hallway...] 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. This is true. This is because the part that we HAVE done is useful in and of itself. It solves some of the problems that currently exist in the Internet. No, it does NOT solve all problems, just as static routing did not solve all routing problems. 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. You misunderstand me Noel. I was not denigrating the comment. I was trying to distinguish naming (editorial) from content (technical). If the objection is that the title is unacceptable because the current draft does not contain topology information and route computation, then I have no objections to changing the title to something like "Source Demand Routing Protocol (Version 1): Part 1: Forwarding and Control Messages". If the objection is that the unconventional map distribution mechanism and route feasibility computation that we intend to use for SDRP (which you haven't seen yet) does not constitute a routing protocol, then I question your definition of a "routing protocol". Tony
- 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