RFC 2092 (rfc2092) - Page 3 of 6
Protocol Analysis for Triggered RIP
Alternative Format: Original Text Document
RFC 2092 Triggered RIP Protocol Analysis January 1997
3.3 Technology Restrictions
There is a small but nontrivial possiblility of an incorrectly
configured or poorly operating link causing severe data loss,
resulting in a 'black hole' in routing. This is often unidirectional
- the link that route updates cross works properly, but not the
return path.
Triggered RIP will NOT fuction properly (and should NOT be used) if a
routing information will be retained/advertised for an arbitrarily
long period of time (until an update in the opposite direction fails
to obtain a response).
To detect black holes in technologies which use PPP encapsulation,
either Echo Request/Response or Link Quality Monitoring should be
used. When a black hole is detected a circuit down indication must
be sent to the routing application.
Current (and future) technologies which do not use PPP, need to use
an equivalent 'are-you-there' mechanism - or should NOT be used with
Triggered RIP.
3.4 Presumption of Reachability
In a stable network there is no requirement to propagate routing
information on a circuit, so if no routing information is (being)
received on a circuit it is assumed that:
o The most recently received information is accurate.
o The intervening path is operational (although there may be no
current connection).
If the circuit manager determines that the intervening path is NOT
operational routing information previously received on that circuit
is timed out. It is worth stressing that it can be ANY routed
datagram which triggers the event.
When the circuit manager re-establishes a connection, the application
exchanges full routing information with its peer.
3.5 Routing Information Flow Control
If the circuit manager reports a circuit as down, the routing
application is flow controlled from sending further information on
the circuit.
Sherry & Meyer Informational