idnits 2.17.1 draft-ietf-ospf-dc-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '... SHOULD probe each other. While the ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2004) is 7405 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2328' is defined on line 192, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sira Panduranga Rao 3 Internet Draft UTA 4 Expiration Date: July 2004 Alex Zinin 5 File name: draft-ietf-ospf-dc-07.txt Alcatel 6 Abhay Roy 7 Cisco Systems 9 January 2004 11 Detecting Inactive Neighbors over OSPF Demand Circuits 12 draft-ietf-ospf-dc-07.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its Areas, and its Working Groups. Note that other 21 groups may also distribute working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a "working 27 draft" or "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 OSPF is a link-state intra-domain routing protocol used in IP 38 networks. OSPF behavior over demand circuits is optimized in RFC1793 39 to minimize the amount of overhead traffic. A part of OSPF demand 40 circuit extensions is the Hello suppression mechanism. This technique 41 allows a demand circuit to go down when no interesting traffic is 42 going through the link. However, it also introduces a problem, where 43 it becomes impossible to detect a OSPF-inactive neighbor over such a 44 link. This memo introduces a new mechanism called "neighbor probing" 45 to address the above problem. 47 1. Motivation 49 In some situations, when operating over demand circuits, the remote 50 neighbor may be unable to run OSPF, and, as a possible result, unable 51 to route application traffic. Possible scenarios include: 53 o The OSPF process might have died on the remote neighbor. 55 o Oversubscription (Section 7 of [RFC1793]) may cause a 56 continuous drop of application data at the link level. 58 Problem here is that the local router cannot identify the problems 59 such as this, since Hello exchange is suppressed on demand circuits. 60 If the topology of the network is such that other routers cannot 61 communicate their knowledge about the remote neighbor via flooding, 62 the local router and all routers behind it will never know about the 63 problem, so application traffic may continue being forwarded to the 64 OSPF-incapable router. 66 This memo describes a backward-compatible neighbor probing mechanism 67 based on the details of the standard flooding procedure followed by 68 OSPF routers. 70 2. Proposed Solution 72 The solution this document proposes uses the link-state update 73 packets to detect whether the OSPF process is operational on the 74 remote neighbor. We call this process "Neighbor probing". The idea 75 behind this technique is to allow either of the two neighbors 76 connected over a demand circuit to test the remote neighbor at any 77 time (see Section 2.1). 79 The routers across the demand circuit can be connected by either a 80 point-to-point link, a virtual link, or a point-to-multipoint 81 interface. The case of routers connected by broadcast networks or 82 NBMA is not considered, since Hello suppression is not used in these 83 cases (Section 3.2 [RFC1793]). 85 The neighbor probing mechanism is used as follows. After a router 86 has synchronized the LSDB with its neighbor over the demand circuit, 87 the demand circuit may be torn down if there is no more application 88 traffic. When application traffic starts going over the link, the 89 link is brought up. If ospfIfDemandNbrProbe is enabled, the routers 90 SHOULD probe each other. While the link is up, the routers may also 91 periodically probe each other every ospfIfDemandNbrProbeInterval. 92 Neighbor probing should not be considered as interesting traffic and 93 do not cause the demand circuit to remain up (relevant details of 94 implementation are outside of the scope of this document). 96 The case when one or more of the router's links are oversubscribed 97 (see section 7 of [RFC1793]) should be considered by the 98 implementations. In such a situation even if the link status is up 99 and application data is being sent on the link, only a limited number 100 of neighbors is really reachable. To make sure temporarily 101 unreachable neighbors are not mistakenly declared down, Neighbor 102 probing should be restricted to those neighbors that are actually 103 reachable (i.e., there is a circuit established with the neighbor at 104 the moment the probing procedure needs to be initiated). This check 105 itself is also considered an implementation detail. 107 2.1 Neighbor Probing 109 The neighbor probing method described in this section is completely 110 compatible with standard OSPF implementations, because it is based on 111 standard behavior that must be followed by OSPF implementations in 112 order to keep their LSDBs synchronized. 114 When a router needs to verify OSPF capability of a neighbor reachable 115 through a demand circuit, it should flood to the neighbor any LSA in 116 its LSDB that would normally be sent to the neighbor during the 117 initial LSDB synchronization process (it most cases such an LSA must 118 have already been flooded to the neighbor by the time the probing 119 procedure starts). For example, the router may flood its own 120 router-LSA (without originating a new version), or the neighbor's own 121 router-LSA. If the neighbor is still alive and OSPF-capable, it 122 replies with a link state acknowledgement or a link state update (an 123 implied acknowledgement) and the LSA is removed from the neighbor's 124 retransmission list. The implementations should limit the number of 125 times an LSA can be retransmitted to ospfIfDemandNbrProbeRetxLimit, 126 when used for neighbor probing. If no acknowledgement (explicit or 127 implicit) is received for a predefined period of time, the probing 128 router should treat this as evidence of the neighbor's unreachability 129 (proving wrong the assumption of reachability used in [RFC1793]) and 130 should bring the adjacency down. 132 Note that when the neighbor being probed receives such a link state 133 update packet, the received LSA has the same contents as the LSA in 134 the neighbor's LSDB, and hence should normally not cause any 135 additional flooding. However, since LSA refreshes are not flooded 136 over demand circuits, the received LSA may have a higher Sequence 137 Number. This will result in the first probe LSA being flooded further 138 by the neighbor. Note that if the current version of the probe LSA 139 has already been flooded to the neighbor, it will not be propagated 140 any further by the neighbor. Also note that in any case subsequent 141 (non-first) probe LSAs will not cause further flooding until the 142 LSA's sequence number is incremented. 144 Again, the implementation should insure (through internal mechanisms) 145 that OSPF link state update packets sent over the demand circuit for 146 the purpose of neighbor probing do not prevent that circuit from 147 being torn down. 149 3. Support of Virtual Links and Point-to-multipoint Interfaces 151 Virtual links can be treated analogous to point-to-point links and so 152 the techniques described in this memo are applicable to virtual links 153 as well. The case of point-to-multipoint interface running as demand 154 circuit (section 3.5 [RFC1793]) can be treated as individual 155 point-to-point links, for which the solution has been described in 156 section 2. 158 4. Compatibility issues 160 All mechanisms described in this document are backward-compatible 161 with standard OSPF implementations. 163 5. Considerations 165 In addition to the lost functionality mentioned in Section 6 of 166 [RFC1793], there is an added overhead in terms of the amount of data 167 (link state updates and acknowledgements) being transmitted due to 168 neighbor probing whenever the link is up and thereby increasing the 169 overall cost. 171 6. Acknowledgements 173 The original idea of limiting the number of LSA retransmissions on 174 demand circuits (used as part of the solution described in this 175 document) and its implementation belong to Padma Pillay-Esnault and 176 Derek Yeung. 178 The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR 179 Anand, and Peter Psenak for their comments on this work. 181 A significant portion of Sira's work was carried out as part of the 182 HFCL-IISc Research Project (HIRP), Bangalore, India. He would like to 183 thank the team for their insightful discussions. 185 7. Security Considerations 187 The mechanism described in this document does not modify security 188 aspects of the OSPF routing protocol. 190 8. Normative References 192 [RFC2328] 193 Moy, J., "OSPF Version 2", RFC 2328, April 1998. 195 [RFC1793] 196 Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, 197 April 1995. 199 Appendix A. Configurable Parameters 201 This memo defines the following additional configuration parameters 202 for OSPF interfaces. 204 ospfIfDemandNbrProbe 205 Indicates whether or not neighbor probing is enabled to 206 determine whether or not the neighbor is inactive. Neighbor 207 probing is disabled by default. 209 ospfIfDemandNbrProbeRetxLimit 210 The number of consecutive LSA retransmissions before the 211 neighbor is deemed inactive and the neighbor adjacency is 212 brought down. Sample value is 10 consecutive LSA 213 retransmissions. 215 ospfIfDemandNbrProbeInterval 216 Defines how often the neighbor will be probed. Sample value is 217 2 minutes. 219 Authors' addresses 221 Sira Panduranga Rao Alex Zinin 222 The University of Texas at Arlington Alcatel 223 Arlington, TX 76013 Sunnyvale, CA 224 Email: siraprao@hotmail.com E-mail: zinin@psg.com 226 Abhay Roy 227 Cisco Systems 228 170 W. Tasman Dr. 229 San Jose,CA 95134 230 E-mail: akr@cisco.com