Re: draft-meyer-demandrouting-02.txt
Gerry Meyer <gerry@spider.co.uk> Fri, 27 August 1993 10:14 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01036; 27 Aug 93 6:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01032; 27 Aug 93 6:14 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa04858; 27 Aug 93 6:14 EDT
Received: by atlas.xylogics.com id AA18751 (5.65c/UK-2.1-930726); Fri, 27 Aug 1993 06:14:01 -0400
Received: from relay.pipex.net by atlas.xylogics.com with SMTP id AA19456 (5.65c/UK-2.1-930726); Fri, 27 Aug 1993 06:13:51 -0400
Received: from 134.191.64.3 by relay.pipex.net with SMTP (PP) id <23553-0@relay.pipex.net>; Fri, 27 Aug 1993 11:10:50 +0100
Received: by widow.spider.co.uk; Fri, 27 Aug 93 11:17:09 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Gerry Meyer <gerry@spider.co.uk>
Date: Fri, 27 Aug 1993 11:06:49 +0100
Message-Id: <9529.9308271006@orbweb.spider.co.uk>
Received: by orbweb.spider.co.uk; Fri, 27 Aug 93 11:06:49 +0100
To: fbaker@acc.com, ietf-rip@xylogics.com
Subject: Re: draft-meyer-demandrouting-02.txt
Cc: gerry@spider.co.uk
Fred Baker <fbaker@acc.com> wrote: >< The circuit manager MAY enforce additional security by not accepting >< incoming calls. >(I guess it wouldn't have occurred to me either to put that statement in or >to take it out; I don't care if I MAY or MAY NOT, my customers are going to >require me to screen calls - and if I'm screening your calls out, what >happens in your version of the routing protocol is of no consequence to >me.) OK. The reason I took the sentence out is I am wary of sanctioning any mechanism which appears to make a connection between peer routers asymmetric. >I saw a few editorial changes ("a" -> "an", etc) also. Have I missed anything? The rambling last sentence of the Abstract was shortened to make it more to the point and the Acknowledgements have been updated. Thats it. >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Some questions: >what is the relationship between this approach and AURP? Would you >recommend building an RTMP version of Demand Routing (because it relies >only on AppleTalk connectivity) Yes. Demand Routing can readily be applied to RTMP. AURP is an EGP, whereas I very much view my RIP proposal is an IGP. There are clearly applications in which AURP provides the only solution - eg tunneling over long hauls. >or should we lean on somebody to submit >the latest AURP documentation as an Info RFC? They should probably be encouraged to do that anyway. >How about Xerox/3COM and UB RIP (IDP)? Vines? DECNET IV? I don't have specifications for all of these. Correct me if I am wrong. Most have RIP variants which I believe can be handled by my approach. Create command types with the 'usual' values 6, 7 and 8 and insert sequence number, fragment and number of fragments in the routing packet before any routes are listed. Would you feel a short informational memo covering RTMP and other applicable RIP variants would be appropriate? I don't have a solution for DECNET IV (or CLNP) - but if someone wants to invent RIP for these. I wasn't planning to ... >Bridge BPDUs? (he ducks the barrage of aging tomatos...) Or bridging. Gerry
- Re: draft-meyer-demandrouting-02.txt Fred Baker
- Re: draft-meyer-demandrouting-02.txt Gerry Meyer