idnits 2.17.1 draft-erblich-fast-init-lsdb-synch-bma-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 141. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 147. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 163), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 166 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Security Considerations' ) ** 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 document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([OSPF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2, 2006) is 6630 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? 'OSPF' on line 118 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet-Draft Mitchell Erblich 3 March 2, 2006 4 Category: Experimental 6 Fast Initial OSPFv2 LSDB Synchronization for BMA 7 draft-erblich-fast-init-lsdb-synch-bma-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2006). All Rights Reserved. 36 ABSTRACT 38 This memo documents a feature that significantly decreases 39 the initial LSDB synchronization time in Broadcast Multiple 40 Access (BMA) environments. This implementation only requires 41 a single OSPF speaker per psuedo-node to support this 42 functionality. These changes are implicitly supported within 43 the OSPFv2 protocol. This memo is not intended to serve as a 44 model for any other implementation. 46 1. Introduction 48 OSPFv2 BMA environments uses the designated router (DR) to 49 increase the efficiency of LSA exchanges. However, OSPFv2 50 specifies a RouterDeadInterval second wait time when no DR 51 is known and a interface comes up before a DR is elected. 53 The wait-time is the bottleneck that restricts initial LSDB 54 synchronization. This memo transparently uses a implied 55 functionality within the OSPFv2 specification to remove this 56 constraint. All other routers without modification within 57 the local link must accept this modification. 59 The implied assumption of priority and then router-id 60 for DR and backup DR (BDR) election assumes that priority 61 will be set based on the capability of the router. Then 62 after a given time frame all capable routers will have 63 booted and generated a hello. 65 To support a router's interface entering an existing BMA 66 environment where a DR has already been elected, a received 67 hello specifying that a DR election has already taken place 68 is required to be accepted. 70 2. Changes to the OSPFv2 Implementation 72 To extend the OSPFv2 specification, upon interface bringup, 73 the interface changes into a passive mode and normally processes 74 input hello packets. It uses these hellos to determine whether 75 a DR has been specified. 77 The passive interface mode has been in other implementations 78 and allows snooping while it prevents us to transmit hellos or 79 any other OSPF control packets. 81 Given hellos that are in the multiple second interval, 82 statistically seeing a hello from an existing router within 83 a few seconds increases dramatically as the number of OSPF 84 speaking routers increase on an interface. 86 If no DR has been seen in the hello field within a configurable 87 wait-time, we then assume that no DR has been elected for this 88 psuedo-node. We can then safely transmit a hello with the seen 89 neighbors and declare ourselves the DR. To allow a deterministic 90 means of selecting routers in this manner, each type of router 91 should have a different configured priority if more than 1 92 router for a link can declare itself DR. 94 It is also suggested that no wait-time is actually needed when 95 the interface comes up and that re-election will select one of 96 two or more DR declared routers by normal DR election. This 97 secondary functionally allows a OSPF speaking router to take 98 over DR responsibilities. 100 However, depending on the current data flow through that part 101 of the network, local disruptions can occur. Additionally, 102 the DR re-election process will cause additional LSAs to be 103 flooded and SPF computations to occur which will effect routing 104 outside the link area. However, if a router is introduced into 105 a transit network, then a network and router LSAs would be 106 flooded anyway, then possible changed DR-other / DR 107 adjacency reformations becomes a major concern. The changes 108 to minimize these effects are outside the scope of this memo. 110 3. Security Considerations 112 The function described in this document does not create any new 113 security issues for the OSPF protocol. Security considerations for 114 the base OSPF protocol are covered in [OSPF]. 116 4. References 118 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 120 5. Author's Address 122 Mitchell Erblich 123 erblichs@earthlink.net 125 Intellectual Property Statement 127 The IETF takes no position regarding the validity or scope of any 128 Intellectual Property Rights or other rights that might be claimed to 129 pertain to the implementation or use of the technology described in 130 this document or the extent to which any license under such rights 131 might or might not be available; nor does it represent that it has 132 made any independent effort to identify any such rights. Information 133 on the procedures with respect to rights in RFC documents can be 134 found in BCP 78 and BCP 79. 136 Copies of IPR disclosures made to the IETF Secretariat and any 137 assurances of licenses to be made available, or the result of an 138 attempt made to obtain a general license or permission for the use of 139 such proprietary rights by implementers or users of this 140 specification can be obtained from the IETF on-line IPR repository at 141 http://www.ietf.org/ipr. 143 The IETF invites any interested party to bring to its attention any 144 copyrights, patents or patent applications, or other proprietary 145 rights that may cover technology that may be required to implement 146 this standard. Please address the information to the IETF at 147 ietf-ipr@ietf.org. 149 Disclaimer of Validity 151 This document and the information contained herein are provided on an 152 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 153 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 154 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 155 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 156 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 157 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 159 Copyright Statement 161 Copyright (C) The Internet Society (2006). This document is subject 162 to the rights, licenses and restrictions contained in BCP 78, and 163 except as set forth therein, the authors retain all their rights.