unavailable virtual gateways

Robert Woody Woodburn <woody@sparta.com> Mon, 25 May 1992 16:06 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01384; 25 May 92 12:06 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26711; 25 May 92 12:13 EDT
Received: from PIZZA.BBN.COM by NRI.Reston.VA.US id aa26703; 25 May 92 12:13 EDT
Received: from pizza by PIZZA.BBN.COM id aa15394; 25 May 92 12:04 EDT
Received: from BBN.COM by PIZZA.BBN.COM id aa15390; 25 May 92 12:02 EDT
Received: from SPARTA.COM by BBN.COM id aa22499; 25 May 92 12:04 EDT
Received: by sparta.com (5.65/1.34) id AA02485; Mon, 25 May 92 12:09:15 -0400
Date: Mon, 25 May 1992 12:09:15 -0400
From: Robert Woody Woodburn <woody@sparta.com>
Message-Id: <9205251609.AA02485@sparta.com>
To: idpr-wg@bbn.com
In-Reply-To: Martha Steenstrup's message of Fri, 22 May 92 17:27:02 -0400 <9205222134.AA10846@sparta.com>
Subject: unavailable virtual gateways


     If, upon revisiting the implementation, you feel that the cost to
     derivce the unavailable virtual gateways isn't a big deal, then let's
     remove the unavailable virtual gateway list from the Dynamic message.
     Let me know what you think so that I can adjust the protocol
     specification document properly.

At first glance one would think that the unavail VG info would be 
helpful, that is what I thought when I first looked at Lee's code, 
and it suprised me that they were not used.  But when I thought about
it more, it is very tedious to first go through and remove ths link
state info for the VGs not reachable, and then double check the info
for the VGs that are there, since the unreachable list may have gained
some VGs, but lost others that have now become reachable.

It is much simpler and probably a lot faster to just remove all the old 
information associated with with a particular dynamic update and then
incorporate the new connectivity.  My vote is to migrate toward taking
it out, but perhaps we need another independent implementation before
going that far.

wood y