re: single attach doc

Fazil Osman <xlnt!jake!fazil@ucsd.edu> Mon, 04 March 1991 22:05 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa15199; 4 Mar 91 17:05 EST
Received: Mon, 4 Mar 91 17:05:37 EST from ucsd.edu by merit.edu (5.59/1.6)
Received: from xlnt.UUCP by ucsd.edu; id AA02448 sendmail 5.64/UCSD-2.1-sun via UUCP Mon, 4 Mar 91 13:34:06 -0800
Received: from jake by xlnt (5.61/1.34) id AA17195; Mon, 4 Mar 91 13:15:07 -0800
Received: by jake. (4.0/SMI-4.0) id AA09971; Mon, 4 Mar 91 13:16:58 PST
Date: Mon, 4 Mar 91 13:16:58 PST
From: Fazil Osman <xlnt!jake!fazil@ucsd.edu>
Message-Id: <9103042116.AA09971@jake.>
To: fddi@merit.edu
Subject: re: single attach doc
Status: O

I have read Richard Fox's document "Definition of a Proxy IP Bridge for an
FDDI Network". I have a lot of concern about this document. Here are some 
initial ones:

	1. The FDDI commitee has not really resolved how dual MAC stations
	   communicate with each other. As an example, FDDI Station Management
	   (SMT) uses frames to inform other nodes of their neighbor, etc. In
	   a network where some stations have their MAC attached to one ring and
	   other stations have their MACs attached to the second ring, SMT cannot
	   communicate this information between the two rings. The spirit of the
	   commitee was that they would not preclude using the second ring for
	   data transmission, and when any user decides to do that, they would
	   configure their ring in a sensible manner. Such comments as "mandating
	   that all single attached stations  must be put on the primary ring only,
       isn't enough to solve the IP integrity problem, since a twisted ring
	   may end up with single attached stations on both rings " ignore the fact
	   that the FDDI commitee accepted the fact that A-A and B-B connections
	    would occur because of miswiring and that these would be corrected
	   ASAP. Adding more protocols is not the solution. Better configuration
	   control is.

	2. This proposal requires that anyone building a FDDI to FDDI bridge
	   has to have the ability to look inside an FDDI frame at the EARP
	   field, in order to determine whether it is forwarding a frame. An
	   FDDI to FDDI bridge has to be able to filter 400,000 packets/sec.
	   on each port. Adding this extra complexity will kill its performance.
	   Is the problem being solved in the right place? Will a FDDI to FDDI
	   bridge also have to solve the same problem for DECNET and ISO, etc. ?
	   Once again, solve the problem in the right place, i.e. at the FDDI
	  commitee. Either control the configurations or have the commitee come up
	   with solutions that will work for ALL protocols.

	3. I do not understand the first paragraph on page 7 "Providing ..".
	   What are those advantages that are being compromised? I do not understand
	   the comment about EARP frames being forwarded during learning. Is
	   this a problem with EARP ( a protocol that is being proposed to solve
	  the same problem as this Proxy IP bridging) or is the problem with IP?
	   During wrap, users expect a perturbations but these will be limited
	   to fractions of a second.

Our concern is that this proposal is something that will affect ALL FDDI
implementors in order to solve the requirements of a small set of users. There
is no question that their requirements should be addressed. But before we 
invent new protocols, we should explore the things that should be done
differently on that small set of machines to interoperate with the standard
implementations.

fazil osman
xdi
15010 avenue of science, suite 100
san diego, ca 92128
fazil@xlnt.com