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