idnits 2.17.1 draft-keyupate-idr-enhanced-refresh-impl-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 03, 2013) is 3977 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC4223' is defined on line 183, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-idr-bgp-enhanced-route-refresh-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Venkatachalapath 3 Internet-Draft K. Patel 4 Intended status: Experimental Cisco Systems 5 Expires: December 05, 2013 R. Raszuk 6 P. Hiremath 7 NTT I3 8 June 03, 2013 10 Enhanced Route Refresh Implementation Report 11 draft-keyupate-idr-enhanced-refresh-impl-00 13 Abstract 15 This document provides an implementation report for Enhanced Route 16 refresh as defined in draft-ietf-idr-bgp-enhanced-route-refresh-03. 17 The editor did not verify the accuracy of the information provided by 18 respondents or by any alternative means. The respondents are experts 19 with the implementations they reported on, and their responses are 20 considered authoritative for the implementations for which their 21 responses represent. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 05, 2013. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Implementation Forms . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Support for Enhanced Route Refresh Capability . . . . . . 3 65 2.2. Support for Route Refresh Message Subtypes . . . . . . . 3 66 2.3. Enhanced Route Refresh Operations . . . . . . . . . . . . 3 67 2.4. Interoperable Implementations . . . . . . . . . . . . . . 4 68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 4. Security considerations . . . . . . . . . . . . . . . . . . . 4 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 73 6.2. Informative References . . . . . . . . . . . . . . . . . 4 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 It is sometimes necessary to perform routing consistency validations 79 such as checking for possible missing withdraws between BGP speakers 80 [RFC4271]. Currently such validations typically involve off-line, 81 manual operations which can be tedious and time consuming. BGP 82 Enhanced Route Refresh enhances the existing BGP route refresh 83 mechanism to provide for the demarcation of the beginning and the 84 ending of a route refresh (which refers to the complete re- 85 advertisement of the Adj-RIB-Out to a peer, subject to routing 86 policies). BGP Enhanced Route refresh can be used to facilitate on- 87 line, non-disruptive consistency validation of BGP routing updates. 89 This document provides an implementation report for BGP Enhanced 90 Route Refresh as defined in 91 [I-D.ietf-idr-bgp-enhanced-route-refresh]. 93 The editor did not verify the accuracy of the information provided by 94 respondents or by any alternative means. The respondents are experts 95 with the implementations they reported on, and their responses are 96 considered authoritative for the implementations for which their 97 responses represent. 99 2. Implementation Forms 101 Contact and implementation information for person filling out this 102 form: 104 Name: Keyur Patel, Email: keyupate@cisco.com, Vendor: Cisco Systems, 105 Inc. Release: IOS 107 Name: Balaji Venkatachalapathy, Email: bvenkata@cisco.com, Vendor: 108 Cisco Systems, Inc. Release: IOS 110 Name: Robert Raszuk, Email: robert@raszuk.net, Vendor: NTT I3. 111 Release: APGW Automation 113 Name: Prashant Hiremath, Email: prashant@ntti3.com, Vendor: NTT I3. 114 Release: APGW Automation 116 2.1. Support for Enhanced Route Refresh Capability 118 Does the implementation support Sec.2.1. 119 [I-D.ietf-idr-bgp-enhanced-route-refresh] Support for Enhanced Route 120 Refresh Capability? 122 Cisco: YES 124 NTT I3: YES 126 2.2. Support for Route Refresh Message Subtypes 128 Does the implementation support Sec.2.2. 129 [I-D.ietf-idr-bgp-enhanced-route-refresh] Subtypes for Route-Refresh 130 messaage? 132 Cisco: YES 134 NTT I3: YES 136 2.3. Enhanced Route Refresh Operations 138 Does the implementation support Sec.3. 139 [I-D.ietf-idr-bgp-enhanced-route-refresh] procedures for starting a 140 route refresh? 142 Cisco: YES 143 NTT I3: YES 145 Does the implementation support Sec.3. 146 [I-D.ietf-idr-bgp-enhanced-route-refresh] procedures for examining 147 route refresh message subtypes and take appropriate actions? 149 Cisco: YES 151 NTT I3: YES 153 2.4. Interoperable Implementations 155 List other implementations that you have tested interoperability of 156 Diverse Path 158 Cisco IOS 160 NTT I3 162 3. IANA Considerations 164 This document makes no request of IANA. 166 Note to RFC Editor: this section may be removed on publication as an 167 RFC. 169 4. Security considerations 171 No new security issues are introduced to the BGP protocol by this 172 specification. 174 5. Acknowledgements 176 6. References 178 6.1. Normative References 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, March 1997. 183 [RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic", 184 RFC 4223, October 2005. 186 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 187 Protocol 4 (BGP-4)", RFC 4271, January 2006. 189 6.2. Informative References 191 [I-D.ietf-idr-bgp-enhanced-route-refresh] 192 Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced 193 Route Refresh Capability for BGP-4", draft-ietf-idr-bgp- 194 enhanced-route-refresh-03 (work in progress), December 195 2012. 197 Authors' Addresses 199 Balaji Venkatachalapathy 200 Cisco Systems 201 170 West Tasman Drive 202 San Jose, CA 95134 203 US 205 Email: bvenkata@cisco.com 207 Keyur Patel 208 Cisco Systems 209 170 West Tasman Drive 210 San Jose, CA 95134 211 US 213 Email: keyupate@cisco.com 215 Robert Raszuk 216 NTT I3 217 101 S. Ellsworth Ave 218 San Mateo, CA 94401 219 USA 221 Email: robert@raszuk.net 223 Prashant P. Hiremath 224 NTT I3 225 101 S. Ellsworth Ave 226 San Mateo, CA 94401 227 USA 229 Email: prashant@ntti3.com