idnits 2.17.1 draft-ietf-ospf-dc-01.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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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.) ** The abstract seems to contain references ([RFC2328], [RFC1793]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 2001) is 8443 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) -- Missing reference section? 'RFC2328' on line 200 looks like a reference -- Missing reference section? 'RFC1793' on line 204 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: September 2001 Alex Zinin 5 File name: draft-ietf-ospf-dc-01.txt Abhay Roy 6 Cisco Systems 8 March 2001 10 Detecting Inactive Neighbors over OSPF Demand Circuits 11 draft-ietf-ospf-dc-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its Areas, and its Working Groups. Note that other 20 groups may also distribute working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 35 OSPF [RFC2328] is a link-state intra-domain routing protocol used in 36 IP networks. OSPF behavior over demand circuits is optimized in 37 [RFC1793] to minimize the amount of overhead traffic. A part of OSPF 38 demand circuit extensions is the Hello suppression mechanism. This 39 technique allows a demand circuit to go down when no interesting 40 traffic is going through the link. However, it also introduces a 41 problem, where it becomes impossible to detect a OSPF-inactive 42 neighbor over such a link. This memo addresses the above problem by 43 introducing two mechanisms---limitation of the number of LSA 44 retransmits, and neighbor probing. 46 1. Motivation 48 In some situations, when operating over demand circuits, the remote 49 neighbor may be unable to run OSPF, and, as a possible result, unable 50 to route application traffic. Possible scenarios include: 52 o The OSPF process might have died on the remote neighbor. 54 o Oversubscription (Section 7 of [RFC1793]) may cause a continuous 55 drop of application data at the link level. 57 The problem here is that the local router cannot identify the prob- 58 lems such as this, since Hello exchange is suppressed on demand cir- 59 cuits. If the topology of the network is such that other routers 60 cannot communicate their knowledge about the remote neighbor via 61 flooding, the local router and all routers behind it will never know 62 about the problem, so application traffic may continue being for- 63 warded to the OSPF-incapable router. 65 This memo describes two techniques that solve the described problem. 66 First, the number of LSA retransmit attempts on demand circuits is 67 limited. This method addresses most of network scenarios, but alone 68 is not enough to cover all possible cases, so we extend it by intro- 69 ducing a backward-compatible neighbor probing mechanism. 71 2. Proposed Solution 73 The first part of the solution is limiting the number of times LSAs 74 can be retransmitted over a demand circuit. The fact that LSAs are 75 not acknowledged by the remote router is used to detect the fact that 76 the neighbor is not reachable any more. See Section 2.1 for more 77 details. 79 The second part of the solution this document proposes uses LSA 80 update packets to detect whether the OSPF process is operational on 81 the remote neighbor. We call this process "Neighbor probing". The 82 idea behind this technique is to allow either of the two neighbors 83 connected over a demand circuit to test the remote neighbor at any 84 time (see Section 2.2). 86 The routers across the demand circuit can be connected by either a 87 point-to-point link, or a virtual link, or a point-to-multipoint 88 interface. The case of routers connected by broadcast networks or 89 NBMA is not considered, since Hello suppression is not used in these 90 cases (Section 3.2 [RFC1793]). 92 The neighbor probing mechanism is used as follows. After a router 93 has synchronized the LSDB with its neighbor over the demand circuit, 94 the demand circuit may be torn down if there is no more application 95 traffic. When application traffic starts going over the link, the 96 link is brought up, and the routers may probe each other. The routers 97 may also probe each other any time the link is up (could be imple- 98 mented as a configurable option) with the caution that OSPF packets 99 sent as a part of neighbor probing are not considered as interesting 100 traffic and do not cause the demand circuit to remain up (relevant 101 details of implementation are outside of the scope of this document). 103 The case when one or more of the router's links are oversubscribed 104 (see section 7 of [RFC1793]) should be considered by the implementa- 105 tions. In such a situation even if the link status is up and applica- 106 tion data being sent on the link, only a limited number of neighbors 107 is really reachable. To make sure temporarily unreachable neighbors 108 are not mistakenly declared down, Neighbor probing should be res- 109 tricted to those neighbors that are actually reachable (i.e., there 110 is a circuit established with the neighbor at the moment the probing 111 procedure needs to be initiated). This check itself is also con- 112 sidered an implementation detail. 114 2.1 Limiting Number of LSA Retransmissions 116 In the presence of LSAs that need to be flooded through a demand- 117 circuit link, it is possible to identify OSPF-incapable neighbors by 118 limiting the amount of LSA retransmits over a demand circuit. The 119 router should count the number of retransmit attempts for each neigh- 120 bor reachable through a demand-circuit link. When an LSA is ack- 121 nowledged by the neighbor, the router should zero the counter. When 122 the counter reaches a predefined (or configured) value, a KillNbr 123 event should be generated for the neighbor experiencing the problem. 125 Note that this method does not require cooperation of the routers on 126 both sides of a demand circuit and can be used with already installed 127 OSPF routers without requiring them to be upgraded with new software. 128 This method has been implemented by Cisco Systems in 1998, has been 129 widely deployed, and has proven its validity. 131 2.2 Neighbor Probing 133 Because the method described in Section 2.1 is not sufficient to 134 cover the situation when the topology of the network is stable and 135 the demand circuit link does not change its state (and hence no LSAs 136 are flooded through the demand circuit), there must be a mechanism to 137 explicitly verify neighbor's OSPF capability. 139 The neighbor probing method described in this section is completely 140 compatible with standard OSPF implementations, because it is based on 141 standard behavior that must be followed by OSPF implementations in 142 order to keep their LSDBs synchronized. 144 When a router needs to verify OSPF capability of a neighbor reachable 145 through a demand circuit, it should flood to the neighbor any LSA in 146 its LSDB that would normally be sent to the neighbor during the ini- 147 tial LSDB synchronization process (it most cases such LSA must have 148 already been flooded to the neighbor by the time the probing pro- 149 cedure starts). For example, the router may flood its own router-LSA 150 (without originating a new version), or the neighbor's own router- 151 LSA. If the neighbor is still alive and OSPF-capable, it replies with 152 a link state acknowledgement and the LSA is removed from the 153 neighbor's retransmission list. If no acknowledgement is received, 154 the mechanism described in Section 2.1 brings the adjacency down. 156 Note that when the neighbor being probed receives such a link state 157 update packet, it acknowledges the LSA but does not flood it any 158 further synce received copy of the LSA is concidered to be the same 159 as the neighbor's database copy. Because of this property, the link 160 state update based neighbor probing mechanism is localized to the 161 demand circuit and does not increase flooding in the area. 163 Again, the implementation should insure (through internal mechanisms) 164 that OSPF link state update packets sent over the demand circuit for 165 the purpose of neighbor probing do not prevent that circuit from 166 being torn down. 168 3. Support of Virtual Links and Point-to-multipoint Interfaces 170 Virtual links can be treated analogous to point-to-point links and so 171 the techniques described in this memo are applicable to virtual links 172 as well. The case of point-to-multipoint interface running as demand 173 circuit (section 3.5 [RFC1793]) can be treated as individual point- 174 to-point links, for which the solution has been described in section 175 2. 177 4. Compatibility issues 179 All mechanisms described in this document are completely backward- 180 compatible. 182 5. Considerations 184 In addition to the lost functionality mentioned in Section 6 of 185 [RFC1793], there is an added overhead in terms of the amount of data 186 (link state updates and acknowledgements) being transmitted due to 187 neighbor probing whenever the link is up and thereby increasing the 188 overall cost. 190 6. Acknowledgements 191 The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR 192 Anand, and Peter Psenak for their comments on this work. 194 A significant portion of Sira's work was carried out as part of the 195 HFCL-IISc Research Project (HIRP), Bangalore, India. He would like to 196 thank the team for their insightful discussions. 198 7. References 200 [RFC2328] 201 J.Moy, OSPF Version 2. Technical Report RFC2328 Internet Engineer- 202 ing Task Force, 1998 ftp://ftp.isi.edu/in-notes/rfc2328.txt 204 [RFC1793] 205 J.Moy, Extending OSPF to support Demand Circuits. Technical Report 206 RFC1793 Internet Engineering Task Force, 1995 207 ftp://ftp.isi.edu/in-notes/rfc1793.txt 209 8. Authors' addresses 211 Sira Panduranga Rao Alex Zinin 212 The University of Texas at Arlington Cisco Systems 213 Arlington, TX 76013 150 West Tasman Dr. 214 Email: siraprao@hotmail.com San Jose, CA 95134 215 Email: azinin@cisco.com 217 Abhay Roy 218 Cisco Systems 219 170 W. Tasman Dr. 220 San Jose,CA 95134 221 USA 222 E-mail: akr@cisco.com