idnits 2.17.1 draft-ietf-ospf-dc-02.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 (September 2001) is 8259 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 175 looks like a reference -- Missing reference section? 'RFC1793' on line 179 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: March 2002 Alex Zinin 5 File name: draft-ietf-ospf-dc-02.txt Nexsi Systems 6 Abhay Roy 7 Cisco Systems 9 September 2001 11 Detecting Inactive Neighbors over OSPF Demand Circuits 12 draft-ietf-ospf-dc-02.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 36 OSPF [RFC2328] is a link-state intra-domain routing protocol used in 37 IP networks. OSPF behavior over demand circuits is optimized in 38 [RFC1793] to minimize the amount of overhead traffic. A part of OSPF 39 demand circuit extensions is the Hello suppression mechanism. This 40 technique allows a demand circuit to go down when no interesting 41 traffic is going through the link. However, it also introduces a 42 problem, where it becomes impossible to detect a OSPF-inactive 43 neighbor over such a link. This memo addresses the above problem by 44 the neighbor probing mechanism. 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 55 continuous drop of application data at the link level. 57 The problem here is that the local router cannot identify the 58 problems such as this, since Hello exchange is suppressed on demand 59 circuits. 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 63 forwarded to the OSPF-incapable router. 65 This memo describes a backward-compatible neighbor probing mechanism 66 based on the details of the standard flooding procedure followed by 67 OSPF routers. 69 2. Proposed Solution 71 The solution this document proposes uses LSA update packets to detect 72 whether the OSPF process is operational on the remote neighbor. We 73 call this process "Neighbor probing". The idea behind this technique 74 is to allow either of the two neighbors connected over a demand 75 circuit to test the remote neighbor at any time (see Section 2.1). 77 The routers across the demand circuit can be connected by either a 78 point-to-point link, or a virtual link, or a point-to-multipoint 79 interface. The case of routers connected by broadcast networks or 80 NBMA is not considered, since Hello suppression is not used in these 81 cases (Section 3.2 [RFC1793]). 83 The neighbor probing mechanism is used as follows. After a router 84 has synchronized the LSDB with its neighbor over the demand circuit, 85 the demand circuit may be torn down if there is no more application 86 traffic. When application traffic starts going over the link, the 87 link is brought up, and the routers may probe each other. The routers 88 may also periodically probe each other any time the link is up (could 89 be implemented as a configurable option) with the caution that OSPF 90 packets sent as a part of neighbor probing are not considered as 91 interesting traffic and do not cause the demand circuit to remain up 92 (relevant details of implementation are outside of the scope of this 93 document). 95 The case when one or more of the router's links are oversubscribed 96 (see section 7 of [RFC1793]) should be considered by the 97 implementations. In such a situation even if the link status is up 98 and application data being sent on the link, only a limited number of 99 neighbors is really reachable. To make sure temporarily unreachable 100 neighbors are not mistakenly declared down, Neighbor probing should 101 be restricted to those neighbors that are actually reachable (i.e., 102 there is a circuit established with the neighbor at the moment the 103 probing procedure needs to be initiated). This check itself is also 104 considered an implementation detail. 106 2.1 Neighbor Probing 108 The neighbor probing method described in this section is completely 109 compatible with standard OSPF implementations, because it is based on 110 standard behavior that must be followed by OSPF implementations in 111 order to keep their LSDBs synchronized. 113 When a router needs to verify OSPF capability of a neighbor reachable 114 through a demand circuit, it should flood to the neighbor any LSA in 115 its LSDB that would normally be sent to the neighbor during the 116 initial LSDB synchronization process (it most cases such LSA must 117 have already been flooded to the neighbor by the time the probing 118 procedure starts). For example, the router may flood its own router- 119 LSA (without originating a new version), or the neighbor's own 120 router-LSA. If the neighbor is still alive and OSPF-capable, it 121 replies with a link state acknowledgement or a link state update (an 122 implied acknowledgement) and the LSA is removed from the neighbor's 123 retransmission list. The implementations should limit the number of 124 times an LSA can be retransmitted when used for neighbor probing. If 125 no acknowledgement (explicit or implicit) is received for a 126 predefined period of time, the probing router should treat this as 127 evidence of the neighbor's unreachability (proving wrong the 128 assumption of reachability used in [RFC1793]) and should bring the 129 adjacency down. 131 Note that when the neighbor being probed receives such a link state 132 update packet, it acknowledges the LSA but does not flood it any 133 further since received copy of the LSA is concidered to be the same 134 as the neighbor's database copy. Because of this property, the link 135 state update based neighbor probing mechanism is localized to the 136 demand circuit and does not increase flooding in the area. 138 Again, the implementation should insure (through internal mechanisms) 139 that OSPF link state update packets sent over the demand circuit for 140 the purpose of neighbor probing do not prevent that circuit from 141 being torn down. 143 3. Support of Virtual Links and Point-to-multipoint Interfaces 144 Virtual links can be treated analogous to point-to-point links and so 145 the techniques described in this memo are applicable to virtual links 146 as well. The case of point-to-multipoint interface running as demand 147 circuit (section 3.5 [RFC1793]) can be treated as individual point- 148 to-point links, for which the solution has been described in section 149 2. 151 4. Compatibility issues 153 All mechanisms described in this document are backward-compatible 154 with standard OSPF implementations. 156 5. Considerations 158 In addition to the lost functionality mentioned in Section 6 of 159 [RFC1793], there is an added overhead in terms of the amount of data 160 (link state updates and acknowledgements) being transmitted due to 161 neighbor probing whenever the link is up and thereby increasing the 162 overall cost. 164 6. Acknowledgements 166 The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR 167 Anand, and Peter Psenak for their comments on this work. 169 A significant portion of Sira's work was carried out as part of the 170 HFCL-IISc Research Project (HIRP), Bangalore, India. He would like to 171 thank the team for their insightful discussions. 173 7. References 175 [RFC2328] 176 J.Moy, OSPF Version 2. Technical Report RFC2328 Internet Engineer- 177 ing Task Force, 1998 ftp://ftp.isi.edu/in-notes/rfc2328.txt 179 [RFC1793] 180 J.Moy, Extending OSPF to support Demand Circuits. Technical Report 181 RFC1793 Internet Engineering Task Force, 1995 ftp://ftp.isi.edu/in- 182 notes/rfc1793.txt 184 8. Authors' addresses 186 Sira Panduranga Rao Alex Zinin 187 The University of Texas at Arlington Nexsi Systems 188 Arlington, TX 76013 1959 Concourse Drive 189 Email: siraprao@hotmail.com San Jose, CA 95131 190 Email: azinin@nexsi.com 192 Abhay Roy 193 Cisco Systems 194 170 W. Tasman Dr. 195 San Jose,CA 95134 196 USA 197 E-mail: akr@cisco.com