idnits 2.17.1 draft-dong-idr-end-of-rib-use-extension-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: After capability negotiation, if both the peer speaker and local speaker support this capability, then End-of-RIB marker MUST be sent to peer after finishing initial route advertisement, and both speakers MUST use the End-of-RIB marker received from peer as notification of initial exchange completion and trigger of local route processing and further advertisement. If any one of the peering speakers does not support this extension, End-of-RIB MUST not be used in initial route exchange scenario. -- The document date (July 4, 2011) is 4680 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: 'RFC4271' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 193, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 5, 2012 K. Patel 6 Cisco Systems 7 July 4, 2011 9 BGP End-of-RIB Usage Extension and Negotiation 10 draft-dong-idr-end-of-rib-use-extension-00 12 Abstract 14 This document describes the use of BGP End-of-RIB marker in improving 15 BGP routing convergence during initial route exchange. A mechanism 16 to negotiate the extension of End-of-RIB usage is also specified. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. BGP Convergence Problem in Initial Route Exchange . . . . . . . 3 60 3. End-of-RIB Usage Extension . . . . . . . . . . . . . . . . . . 3 61 4. BGP End-of-RIB Capability . . . . . . . . . . . . . . . . . . . 4 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 BGP Graceful Restart (GR) [RFC4724] defines an End-of-RIB marker to 73 convey routing convergence information during BGP restart. It is 74 also specified that the generation of such a marker upon completion 75 of the initial update would be useful for routing convergence in 76 general. 78 Currently most of BGP routers neither generate End-of-RIB marker upon 79 completion of initial route advertisement nor anticipate the arrival 80 of End-of-RIB from peers during initial route exchange. In addition, 81 for some BGP implementations receiving End-of-RIB marker in scenarios 82 other than BGP GR may be treated as an error. 84 This document describes the benefit of using BGP End-of-RIB marker to 85 inform completion of initial BGP route exchange. A mechanism to 86 negotiate the extension of End-of-RIB usage is also specified. 88 2. BGP Convergence Problem in Initial Route Exchange 90 When a BGP speaker establishes BGP sessions with multiple peers, the 91 initial route exchange begins. Normally whenever a route is received 92 from one of the peers, BGP path calculation would be executed and new 93 UPDATE message will be advertised to peers immediately. Since during 94 initial route exchange the BGP speaker may consecutively receive 95 different routes to the same prefixes from different peers, this 96 normal procedure may cause the BGP speaker execute the path 97 calculation for some prefixes for multiple times, and would further 98 result in advertising non-optimal routes before routing convergence. 100 Apparently this is a waste of processing resource and also impacts 101 routing convergence and stability of the network. Some optimization 102 has been proposed. One typical approach is to set a timer for 103 initial route exchange, and BGP speaker will not execute path 104 calculation and advertise routes to peers until that timer expires. 105 The disadvantage of this approach is value of the timer would be 106 critical for BGP convergence performance, and since the timer value 107 would be fixed once configured, it cannot guarantee best performance 108 and convergence time for different cases. 110 3. End-of-RIB Usage Extension 112 [RFC4724] defines the use of End-of-RIB marker in BGP Graceful 113 Restart scenario, and it also specifies that "generation of such a 114 marker upon completion of the initial update would be useful for 115 routing convergence in general, and thus the practice is 116 recommended". 118 Actually End-of-RIB marker should be used as an individual feature 119 independent of whether BGP GR is enabled or not. One example is 120 [RFC4684] specifies the use of End-of-RIB for RT Membership 121 information advertisement. 123 Similar to the use in BGP Graceful Restart, End-of-RIB marker could 124 also be used to inform completion of initial route exchange. Thus 125 route calculation and further advertisement would be suspended until 126 End-of-RIB marker is received from all or a predefined portion of BGP 127 peers. In addition, a relative large timer could be used as a backup 128 trigger to ensure path calculation and advertisement would always be 129 executed within a predefined time range. 131 Although it is easy to understand the use of End-of-RIB in improving 132 initial routing convergence, such benefit may not be obtained 133 directly, as currently most of BGP routers neither generate End-of- 134 RIB marker upon completion of initial route advertisement nor 135 anticipate the arrival of End-of-RIB from peers during initial route 136 exchange. In addition, for some BGP implementations receiving End- 137 of-RIB marker in scenarios other than BGP GR may be treated as an 138 error. Thus to use End-of-RIB for initial route exchange scenario, 139 some negotiation between the sending and receiving BGP speaker would 140 be necessary. 142 4. BGP End-of-RIB Capability 144 A new BGP capability called End-of-RIB Capability is defined. The 145 Capability code for this capability is to be assigned. The 146 Capability length field is zero. 148 By advertising this capability to a peer, a BGP speaker conveys to 149 the peer that the speaker support advertising and receiving End-of- 150 RIB marker and the related procedures described in this document. 152 After capability negotiation, if both the peer speaker and local 153 speaker support this capability, then End-of-RIB marker MUST be sent 154 to peer after finishing initial route advertisement, and both 155 speakers MUST use the End-of-RIB marker received from peer as 156 notification of initial exchange completion and trigger of local 157 route processing and further advertisement. If any one of the 158 peering speakers does not support this extension, End-of-RIB MUST not 159 be used in initial route exchange scenario. 161 When End-of-RIB is used for initial exchange, a timer MAY also be 162 used to control the maximum initial delay of route processing and 163 UPDATEs advertisement. The timer value SHOULD be configurable. 165 5. IANA Considerations 167 A new BGP capability - End-of-RIB Capability is defined in this 168 document. The Capability code needs to be assigned by the IANA. 170 6. Security Considerations 172 This document does not change the security properties of BGP. 174 7. Acknowledgements 176 The authors would like to thank John Scudder, Shunwan Zhuang, Qing 177 Zeng for their valuable comments and discussions to this document. 179 8. References 181 8.1. Normative References 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, March 1997. 186 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 187 Protocol 4 (BGP-4)", RFC 4271, January 2006. 189 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 190 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 191 January 2007. 193 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 194 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 195 May 2008. 197 8.2. Informative References 199 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 200 R., Patel, K., and J. Guichard, "Constrained Route 201 Distribution for Border Gateway Protocol/MultiProtocol 202 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 203 Private Networks (VPNs)", RFC 4684, November 2006. 205 Authors' Addresses 207 Jie Dong 208 Huawei Technologies 209 Huawei Building, No.3 Xinxi Rd 210 Beijing, 100085 211 China 213 Email: jie.dong@huawei.com 215 Mach Chen 216 Huawei Technologies 217 Huawei Building, No.3 Xinxi Rd 218 Beijing, 100085 219 China 221 Email: mach.chen@huawei.com 223 Keyur Patel 224 Cisco Systems 225 170 W. Tasman Drive 226 San Jose, CA 95134 227 USA 229 Email: keyupate@cisco.com