Re: Routing over Demand Circuits

Art Berggreen <art@opal.acc.com> Mon, 16 August 1993 18:07 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05198; 16 Aug 93 14:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05193; 16 Aug 93 14:07 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa29046; 16 Aug 93 14:07 EDT
Received: by atlas.xylogics.com id AA19279 (5.65c/UK-2.1-930726); Mon, 16 Aug 1993 14:09:40 -0400
Received: from OPAL.ACC.COM by atlas.xylogics.com with SMTP id AA27577 (5.65c/UK-2.1-930726); Mon, 16 Aug 1993 14:09:28 -0400
Received: by opal.acc.com (4.1/SMI-4.0) id AA00568; Mon, 16 Aug 93 11:04:47 PDT
Date: Mon, 16 Aug 1993 11:04:47 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Art Berggreen <art@opal.acc.com>
Message-Id: <9308161804.AA00568@opal.acc.com>
To: gerry@spider.co.uk, ietf-rip@xylogics.com
Subject: Re: Routing over Demand Circuits

>
>>I'm sorry, but I see no reason not to use TCP here.
>
>I would also add there may be (no, are) routers out there which don't have
>a TCP stack or particularly require to use one.  While I am pro-TCP/IP, is
>imposing a TCP/IP stack on others in this instance not being a bit dogmatic?

Another assumption that I'm concerned about, is that the TCP/IP packets will
follow that same path as the protocol whose routing information is being
exchanged.  Due to the details of the IP routing metrics/dynamics or the
configuration, the IP packets may take a different physical path than that
desired for the specific protocol.  I can certainly envision a box with
two demand interfaces, one configured to carry a particular protocol (IPX
for example) and the other to carry IP.  Just because the IP path can be
established doesn't guarantee the other path.

I'd also be concerned that using TCP would involve more configuration than
if the routing information were carried in native packets of a protocol
you already have configured.

Art