idnits 2.17.1 draft-zhang-idr-transitive-gr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC4724, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4724, updated by this document, for RFC5378 checks: 2000-12-19) -- 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 25, 2013) is 4012 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Zhang 3 Internet-Draft HangZhou H3C Co. Limited 4 Updates: RFC 4724 (if approved) A. Retana 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: September 26, 2013 March 25, 2013 8 Transitive BGP Graceful Restart 9 draft-zhang-idr-transitive-gr-02 11 Abstract 13 This document defines an extension to BGP Graceful Restart that 14 reduces the negative impact of multiple inter-connected routers 15 restarting. The proposed mechanism does not require any changes to 16 the BGP protocol. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 18, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 54 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 60 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The BGP Graceful Restart [RFC4724] process defines a mechanism that a 66 restarting router can use with its non-restarting peers. The 67 existence of other restarting routers results in the use of the base 68 route exchange mechanism [RFC4271] with them, even if the forwarding 69 state has indeed been preserved for (and by) those peers during the 70 restart. As a result, traffic forwarding between restarting routers 71 is disrupted. 73 This document defines an extension to BGP Graceful Restart that 74 reduces the negative impact of multiple inter-connected restarting 75 routers. The proposed mechanism does not require any changes to the 76 BGP protocol. 78 The current process [RFC4724] states that routes from restarting 79 peers are to be removed from the local forwarding state when the non- 80 restarting peers converge (the End-of-RIB marker is received from all 81 of them). Assuming a simple topology: 83 NR1 - R2 - R3 - NR2 85 where NRx are non-restarting routers, Rx are restarting routers 86 and the lines between them represent BGP sessions. 88 There are two types of routes affected (from R2's point of view) by 89 the current process: 91 1. Routes that are only reachable through R3. These routes will be 92 removed from the forwarding table when the non-restarting routers 93 converge, and installed back in when the convergence with R3 is 94 done. 96 2. Routes that are reachable through both R3 and NR1. These routes 97 will first change to NR1 when the non-restarting routers 98 converge, and later back to R3 (assuming that is in fact still 99 the preferred path). 101 Both types can clearly cause disruption in traffic forwarding, micro- 102 loops, traffic loss, etc. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Proposed Solution 112 The extension proposed to BGP Graceful Restart to accommodate for 113 multiple restarting routers, when the forwarding state has been 114 preserved between them, is simply to delay sending the End-of-RIB 115 marker to non-restarting routers. 117 Specifically, to allow a restarting router the ability to reduce the 118 impact due to other restarting routers, the following paragraph is 119 added as the fifth one in section 4.1 (Procedures for the Restarting 120 Speaker) [RFC4724]: 122 Before updating the corresponding forwarding states, the 123 Restarting Speaker MAY start a path calculation after all non- 124 retarting peers's End-Of-RIB marker have been received, and 125 advertise the Adj-RIB-Out to its restarting peers (ones with the 126 "Restart State" bit set in the received capability), including the 127 End-of-RIB marker, and wait for the corresponding End-of-RIB 128 marker from them. 130 In order to maintain the transitive property when more than two BGP 131 speakers peering with each other restart, the following paragraph is 132 added as the sixth one in section 4.1 (Procedures for the Restarting 133 Speaker) [RFC4724]: 135 If the Restarting Speaker has multiple restarting peers, sending 136 the End-of-RIB marker SHOULD be delayed until all the markers from 137 those restarting peers have been received. The BGP speaker on a 138 given connection SHOULD send its End-of-RIB marker if the pair 139 hasn't sent or received UPDATES for a locally configured time 140 period (which SHOULD be significantly less than the 141 Selection_Deferral_Timer). 143 During the recovery period of multiple restarting routers, a BGP 144 speaker may advertise routing information that is not being used at 145 the time. Because the forwarding state of the speakers remains 146 unchanged (from that at the restart), it is clear that this 147 transitive property of sharing routing information between restarting 148 routers doesn't cause any issues in the actual forwarding of traffic. 149 Furthermore, it has the advantage if avoiding further disruptions in 150 the forwarding of traffic through the restarting routers. 152 4. Security Considerations 154 This document proposes an extension to an existing mechanism. The 155 same security considerations explained there apply to this extension. 157 The propagation of routing information that is not in use may cause 158 forwarding loops and an inconsistent state in a network. However, 159 the risk in this document is mitigated by the fact that the 160 information is validated by all peers once the convergence process 161 completes. 163 5. IANA Considerations 165 This document has no IANA actions. 167 6. Acknowledgements 169 The authors would like to thank Enke Chen, John Scudder, Robert 170 Raszuk and Abhay Roy for their feedback. 172 7. References 174 7.1. Normative References 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 180 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 181 January 2007. 183 7.2. Informative References 185 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 186 Protocol 4 (BGP-4)", RFC 4271, January 2006. 188 Authors' Addresses 190 Haifeng Zhang 191 HangZhou H3C Co. Limited 192 310 Liuhe Road, Zhijiang Science Park 193 Hangzhou 194 P.R. China 196 Email: zhanghf@h3c.com 197 Alvaro Retana 198 Cisco Systems, Inc. 199 7025 Kit Creek Rd. 200 Research Triangle Park, NC 27709 201 USA 203 Email: aretana@cisco.com