draft-ietf-ospf-dc-02.txt   draft-ietf-ospf-dc-03.txt 
Network Working Group Sira Panduranga Rao Network Working Group Sira Panduranga Rao
Internet Draft UTA Internet Draft UTA
Expiration Date: March 2002 Alex Zinin Expiration Date: April 2002 Alex Zinin
File name: draft-ietf-ospf-dc-02.txt Nexsi Systems File name: draft-ietf-ospf-dc-03.txt Nexsi Systems
Abhay Roy Abhay Roy
Cisco Systems Cisco Systems
September 2001 October 2001
Detecting Inactive Neighbors over OSPF Demand Circuits Detecting Inactive Neighbors over OSPF Demand Circuits
draft-ietf-ospf-dc-02.txt draft-ietf-ospf-dc-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts. groups may also distribute working documents as Internet Drafts.
skipping to change at page 3, line 23 skipping to change at page 3, line 23
2.1 Neighbor Probing 2.1 Neighbor Probing
The neighbor probing method described in this section is completely The neighbor probing method described in this section is completely
compatible with standard OSPF implementations, because it is based on compatible with standard OSPF implementations, because it is based on
standard behavior that must be followed by OSPF implementations in standard behavior that must be followed by OSPF implementations in
order to keep their LSDBs synchronized. order to keep their LSDBs synchronized.
When a router needs to verify OSPF capability of a neighbor reachable When a router needs to verify OSPF capability of a neighbor reachable
through a demand circuit, it should flood to the neighbor any LSA in through a demand circuit, it should flood to the neighbor any LSA in
its LSDB that would normally be sent to the neighbor during the its LSDB that would normally be sent to the neighbor during the
initial LSDB synchronization process (it most cases such LSA must initial LSDB synchronization process (it most cases such an LSA must
have already been flooded to the neighbor by the time the probing have already been flooded to the neighbor by the time the probing
procedure starts). For example, the router may flood its own router- procedure starts). For example, the router may flood its own router-
LSA (without originating a new version), or the neighbor's own LSA (without originating a new version), or the neighbor's own
router-LSA. If the neighbor is still alive and OSPF-capable, it router-LSA. If the neighbor is still alive and OSPF-capable, it
replies with a link state acknowledgement or a link state update (an replies with a link state acknowledgement or a link state update (an
implied acknowledgement) and the LSA is removed from the neighbor's implied acknowledgement) and the LSA is removed from the neighbor's
retransmission list. The implementations should limit the number of retransmission list. The implementations should limit the number of
times an LSA can be retransmitted when used for neighbor probing. If times an LSA can be retransmitted when used for neighbor probing. If
no acknowledgement (explicit or implicit) is received for a no acknowledgement (explicit or implicit) is received for a
predefined period of time, the probing router should treat this as predefined period of time, the probing router should treat this as
evidence of the neighbor's unreachability (proving wrong the evidence of the neighbor's unreachability (proving wrong the
assumption of reachability used in [RFC1793]) and should bring the assumption of reachability used in [RFC1793]) and should bring the
adjacency down. adjacency down.
Note that when the neighbor being probed receives such a link state Note that when the neighbor being probed receives such a link state
update packet, it acknowledges the LSA but does not flood it any update packet, the received LSA has the same contents as the LSA in
further since received copy of the LSA is concidered to be the same the neighbor's LSDB. However, since LSA refreshes are not flooded
as the neighbor's database copy. Because of this property, the link over demand circuits, the received LSA may have a higher Sequence
state update based neighbor probing mechanism is localized to the Number. This will result in the first probe LSA being flooded further
demand circuit and does not increase flooding in the area. by the neighbor. Note that if the current version of the probe LSA
has already been flooded to the neighbor, it will not be propagated
any further by the neighbor. Also note that in any case subsequent
(non-first) probe LSAs will not effect further flooding until the
LSA's sequence number is incremented.
Again, the implementation should insure (through internal mechanisms) Again, the implementation should insure (through internal mechanisms)
that OSPF link state update packets sent over the demand circuit for that OSPF link state update packets sent over the demand circuit for
the purpose of neighbor probing do not prevent that circuit from the purpose of neighbor probing do not prevent that circuit from
being torn down. being torn down.
3. Support of Virtual Links and Point-to-multipoint Interfaces 3. Support of Virtual Links and Point-to-multipoint Interfaces
Virtual links can be treated analogous to point-to-point links and so Virtual links can be treated analogous to point-to-point links and so
the techniques described in this memo are applicable to virtual links the techniques described in this memo are applicable to virtual links
as well. The case of point-to-multipoint interface running as demand as well. The case of point-to-multipoint interface running as demand
circuit (section 3.5 [RFC1793]) can be treated as individual point- circuit (section 3.5 [RFC1793]) can be treated as individual point-
to-point links, for which the solution has been described in section to-point links, for which the solution has been described in section
2. 2.
4. Compatibility issues 4. Compatibility issues
All mechanisms described in this document are backward-compatible All mechanisms described in this document are backward-compatible
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/