Re: minutes of RIPv2 meeting in Amsterdam

[Gerry Meyer <[e-mail]>]

Gilbert Moineau <[e-mail]> wrote:

>A problem I can see with "b" is for IPX, according RFC1356, to send your
>Netware SAP/RIP packet to the same VC as the router traffic, you would need
>the NULL encapsulation or you have to use another VC with the UDF to 0xCC
>just for the Netware SAP/RIP traffic.

Yes I have that one down in my con column for TCP.   Having said that if I
were routing more than one protocol I would encourage NULL encapsulation
anyway.

Since the other implementation (by XtcN) of my draft I know of is an IPX only
implementation, I imagine that vendor would not welcome having to add a TCP
stack.

    Gerry

---------- My original mailing  ----------
From: ietf-rip-request
To: ariel; ietf-rip
Cc: gerry
Subject: Re: minutes of RIPv2 meeting in Amsterdam
Date: 20 July, 1993 15:30


>Gerry Meyer's Demand Routing proposal was discussed at length.  It was
>agreed that it performed a useful function.  However, Robert Ullman
>pointed out that it simulated many of the functions of TCP and that RAP
>used TCP.  Robert and Gerry will continue the discussion after Gerry
>has had an opportunity to read the RAP RFC.  The slides from Gerry's
>presentation are included in these Proceedings.

Like all other current routing protocols, RAP (experimental RFC 1476)
currently does not address the problem of running a routing protocol on
a switched network.  It is also IP-specific in its current form.
I feel RAP is a red-herring in this discussion.

The real issue is what is the most appropriate method to operate on demand
circuits with RIP protocol variants (IP, Novell, Apple etc):

(a) an appropriate unreliable service (UDP-IP, IPX etc) which is what we
    currently use and is proposed in the Internet Draft.

(b) over a single reliable transport (TCP, encapsulating Novell RIP etc),

(c) the 'appropriate' reliable transport (TCP for IP, NCP or SPX for Novell
    etc).

I think the 'best' method depends on where you are coming from.  I rule
out (c) immediately as requiring transports not otherwise required in a
multi-protocol router.

How I intend to proceed is to sketch through case (b) for myself to see
what functionality it can provide.   I will then mail a list of pros and
cons for the two methods for a discussion on the mailing list.

    Gerry