idnits 2.17.1 draft-keyur-bgp-enhanced-route-refresh-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 5 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 6 pages 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 -- The document date (March 30, 2011) is 4774 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 (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet Draft E. Chen 4 Intended Status: Standards Track B. Venkatachalapathy 5 Expiration Date: Oct. 1, 2011 Cisco Systems 6 March 30, 2011 8 Enhanced Route Refresh Capability for BGP-4 9 draft-keyur-bgp-enhanced-route-refresh-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and 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/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on October 1, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 In this document we enhance the existing BGP route refresh mechanisms 52 to provide for the demarcation of the beginning and the ending of a 53 route refresh. The enhancement can be used to facilitate on-line, 54 non-disruptive consistency validations of BGP routing updates. 56 1. Introduction 58 It is sometimes necessary to perform routing consistency validations 59 such as checking for possible missing withdraws between BGP speakers 60 [RFC4271]. Currently such validations typically involve off-line, 61 manual operations which can be tedious and time consuming. 63 In this document we enhance the existing BGP route refresh mechanisms 64 [RFC2918] to provide for the demarcation of the beginning and the 65 ending of a route refresh (which refers to the complete re- 66 advertisement of the Adj-RIB-Out to a peer, subject to routing 67 policies). The enhancement can be used to facilitate on-line, non- 68 disruptive consistency validation of BGP routing updates. 70 1.1. Specification of Requirements 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Protocol Extensions 78 The BGP protocol extensions introduced in this document include the 79 definition of a new BGP capability, named "Enhanced Route Refresh 80 Capability", and the specification of the message subtypes for the 81 ROUTE-REFRESH message. 83 2.1. Enhanced Route Refresh Capability 85 The "Enhanced Route Refresh Capability" is a new BGP capability 86 [RFC5492]. The Capability Code for this capability is specified in 87 the IANA Considerations section of this document. The Capability 88 Length field of this capability is zero. 90 By advertising this capability to a peer, a BGP speaker conveys to 91 the peer that the speaker supports the message subtypes for the 92 ROUTE-REFRESH message and the related procedures described in this 93 document. 95 2.2. Subtypes for ROUTE-REFRESH Message 97 The "Reserved" field of the ROUTE-REFRESH message specified in 98 [RFC2918] is re-defined as the "Message Subtype" with the following 99 values: 101 0 - Normal route refresh request [RFC2918] 102 with/without ORF [RFC5291] 103 1 - Demarcation of the beginning of a route refresh 104 2 - Demarcation of the ending of a route refresh 106 The use of the message subtypes is described in the Operations 107 section. 109 3. Operations 111 A BGP speaker that support the message subtypes for the ROUTE-REFRESH 112 message and the related procedures SHOULD advertise the "Enhanced 113 Route Refresh Capability". 115 The following procedures are applicable only if a BGP speaker has 116 received the "Enhanced Route Refresh Capability" from a peer. 118 Before the speaker starts a route refresh that is either initiated 119 locally, or in response to a "normal route refresh request" from the 120 peer, the speaker MUST send a ROUTE-REFRESH message with the 121 specified message subtype to mark the beginning of the route refresh. 122 After the speaker completes the re-advertisement of the entire Adj- 123 RIB-Out to the peer, it MUST send a ROUTE-REFRESH message with the 124 specified message subtype to mark the ending of the route refresh. 126 Conceptually the "entire ADJ-RIB-Out" for a peer in this section 127 refers to all the route entries in the "ADJ-RIB-Out" for the peer at 128 the start of the route refresh. When a route entry in the "ADJ-RIB- 129 Out" changes, the advertisement of the modified route entry (instead 130 of the snapshot entry) would suffice. 132 In processing a ROUTE-REFRESH message from a peer, the BGP speaker 133 MUST examine the "message subtype" field of the message and take the 134 appropriate actions. The BGP speaker SHALL use the demarcations of 135 the beginning and the ending of a route refresh to perform 136 consistency validations of the updates received from the peer. All 137 the routes that were not re-advertised in the route refresh MUST be 138 purged, and SHOULD be logged for further analysis. 140 4. Error Handling 142 This document defines a new NOTIFICATION error code: 144 Error Code Symbolic Name 146 ROUTE-REFRESH Message Error 148 The following error subcodes are defined as well: 150 Subcode Symbolic Name 152 1 Invalid Message Length 154 The error handling specified in this section is applicable only when 155 a BGP speaker has received the "Enhanced Route Refresh Capability" 156 from a peer. 158 When the BGP speaker detects an error while processing a ROUTE- 159 REFRESH message with a non-zero "Message Subtype" field, it MUST send 160 a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error". 161 The Data field of the NOTIFICATION message MUST contain the complete 162 ROUTE-REFRESH message. 164 If the length, excluding the fixed-size message header, of the 165 ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the 166 error subcode is set to "Invalid Message Length". 168 5. IANA Considerations 170 This document defines the Enhanced Route Refresh Capability for BGP. 171 The Capability Code needs to be assigned by the IANA. 173 In addition, this document defines an NOTIFICATION error code and 174 several error subcodes for the ROUTE-REFRESH message. They need to 175 be registered with the IANA. 177 6. Security Considerations 179 This extension to BGP does not change the underlying security issues. 181 7. Acknowledgments 183 The authors would like to thank Pedro Marques, Pradosh Mohapatra, 184 Robert Raszuk, Pranav Mehta, and Shyam Sethuram for discussions and 185 review. The authors would like to thank Martin Djernaes, Jeff haas, 186 Ilya Varlashkin, Rob Shakir, Paul Jakma, Jie Dong, Qing Zeng, Albert 187 Tian, and Jakob Heitz for their review and comments. 189 8. Normative References 191 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 192 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 193 2006. 195 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", 196 RFC 2918, September 2000. 198 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 199 with BGP-4", RFC 5492, February 2009. 201 [RFC5291] Chen, E., and Rekhter, Y., "Outbound Route Filtering 202 Capability for BGP-4", RFC 5291, August 2008. 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 9. Authors' Addresses 209 Keyur Patel 210 Cisco Systems 212 Email: keyupate@cisco.com 214 Enke Chen 215 Cisco Systems 217 Email: enkechen@cisco.com 219 Balaji Venkatachalapathy 220 Cisco Systems 221 Email: bvenkata@cisco.com