Re: Single subnet

Dave Katz <katz@merit.edu> Mon, 21 May 1990 02:52 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa18507; 20 May 90 22:52 EDT
Received: Sun, 20 May 90 21:51:23 EST by merit.edu (5.59/1.6)
Date: Sun, 20 May 90 21:51:23 EST
From: Dave Katz <katz@merit.edu>
Message-Id: <9005210251.AA03028@merit.edu>
To: deering@pescadero.stanford.edu
Subject: Re: Single subnet
Cc: fddi@merit.edu
Status: O

>If all the ISs are dual-MACed, unwrapping does not cause any ISs to
>disappear from either of the two resulting subnetworks.  So, for this
>to work, it would have to be the loss of an IS *at a specific MAC address*
>that triggers the solicitation of ES configuration.  Is that the case?
>
>Also, if there is only one (dual-MAC) IS attached to the FDDI network,
>it would have to detect the loss of connectivity between its *own* two
>MACs, and use that to trigger ES solicitation.  Is that the case?
 
The ES solicitation is triggered by "a change in the set of Intermediate
Systems on the LAN, or a change in the Designated Intermediate System ID,"
so depending on how you read (and/or implement) this statement, it may
or may not work.  ISs are identified for most purposes by their network
address (actually their ID, a subset thereof), but adjacencies are based
on MAC addresses.  I would lean toward the interpretation that the set
of ISs is based on router ID, which wouldn't change in either case.

I think that the suggested ES hello timer sent by ISs should be cranked
way down (from 600 seconds to 20 or something..).  Given the available
bandwidth, messages that often wouldn't bother anybody.

>unwrap event.  (I suppose a fancy IS would load split across the two
>rings, so half the packets would get through.  Are the transport
>protocols expected to cope with that?)
 
A fancy IS could load split, although I tend to think that load splitting
is really only useful between ESs on the same FDDI network (unless the
FDDI network is a bottleneck in global routing).  In any case, it's
an issue for the forwarding engine, not the routing protocol or the
transport entity (just like IP).