idnits 2.17.1 draft-ietf-idr-bgp-issues-06.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 : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 27, 2012) is 4385 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N' is mentioned on line 940, but not defined == Missing Reference: 'RWStevens' is mentioned on line 1311, but not defined -- Looks like a reference, but probably isn't: '1' on line 1842 == Missing Reference: 'RFC904' is mentioned on line 6125, but not defined -- Looks like a reference, but probably isn't: '12' on line 3043 -- Looks like a reference, but probably isn't: '10' on line 4083 == Missing Reference: 'RFC793' is mentioned on line 4091, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) -- Looks like a reference, but probably isn't: '13' on line 4646 == Missing Reference: 'Event 9' is mentioned on line 5211, but not defined == Missing Reference: 'Event17' is mentioned on line 7613, but not defined == Missing Reference: 'Event 18' is mentioned on line 7884, but not defined == Missing Reference: 'Event 19' is mentioned on line 5061, but not defined == Missing Reference: 'Event 14' is mentioned on line 7218, but not defined == Missing Reference: 'Event 13' is mentioned on line 5803, but not defined == Missing Reference: 'Event 17' is mentioned on line 7592, but not defined == Missing Reference: 'Event 22' is mentioned on line 5812, but not defined == Missing Reference: 'Event 15' is mentioned on line 5804, but not defined == Missing Reference: 'Event 1' is mentioned on line 6676, but not defined == Missing Reference: '3-6' is mentioned on line 6682, but not defined == Missing Reference: 'Event1' is mentioned on line 6682, but not defined == Missing Reference: 'Events 7-8' is mentioned on line 7427, but not defined == Missing Reference: '10-11' is mentioned on line 7427, but not defined -- Looks like a reference, but probably isn't: '18' on line 7427 == Missing Reference: '20-27' is mentioned on line 7427, but not defined == Missing Reference: 'Event24' is mentioned on line 7537, but not defined == Missing Reference: 'Event18' is mentioned on line 7666, but not defined == Missing Reference: 'Event2' is mentioned on line 7784, but not defined == Missing Reference: 'Event 2' is mentioned on line 7762, but not defined == Missing Reference: 'Event 25' is mentioned on line 7887, but not defined == Unused Reference: 'RFC1771' is defined on line 8120, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 8123, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 8126, but no explicit reference was found in the text == Unused Reference: 'RFC3392' is defined on line 8143, but no explicit reference was found in the text == Unused Reference: 'RFC4065' is defined on line 8146, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 8149, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2842 (Obsoleted by RFC 3392) -- Obsolete informational reference (is this intentional?): RFC 3065 (Obsoleted by RFC 5065) -- Obsolete informational reference (is this intentional?): RFC 3392 (Obsoleted by RFC 5492) Summary: 2 errors (**), 0 flaws (~~), 33 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR A. Lange 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational March 27, 2012 5 Expires: September 28, 2012 7 Issues in Revising BGP-4 (RFC1771 to RFC4271) 8 draft-ietf-idr-bgp-issues-06 10 Abstract 12 This document records the issues discussed and the consensus reached 13 in the Interdomain Routing (IDR) Working Group during its efforts to 14 revise and bring up to date the base specification for the BGP-4 15 protocol as documented in RFC1771. The document focuses on the 16 changes tracked from August 2002 when the last major push for 17 revision began. The results of these efforts are encoded in RFC4271, 18 which should be taken as normative for any of the issues that were 19 discussed. The discussion here is intended to record how and why 20 some of the changes to BGP were made. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 28, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2. The Issues from -17 to -18 . . . . . . . . . . . . . . . . . 6 58 2.1. IDR WG Charter . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.3. FSM wording for what state BGP accepts connections in . . 8 61 2.4. BGP Identifier/Router ID . . . . . . . . . . . . . . . . 8 62 2.5. Direct EBGP Peers . . . . . . . . . . . . . . . . . . . . 8 63 2.6. Disallow Private Addresses . . . . . . . . . . . . . . . 9 64 2.7. Renumber Appendix Sections . . . . . . . . . . . . . . . 9 65 2.8. Jitter Text . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.9. Reference to RFC904 - EGP Protocol . . . . . . . . . . . 14 67 2.10. Extending AS_PATH Attribute . . . . . . . . . . . . . . . 14 68 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 69 9.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 2.11.1. Rules for routes from Loc-RIB to Adj-RIB-Out - 71 Section 9.1.3 . . . . . . . . . . . . . . . . . . . 18 72 2.11.2. Rules for routes from Loc-RIB to Adj-RIB-Out - 73 Section 2 . . . . . . . . . . . . . . . . . . . . . 19 74 2.11.3. Documenting IBGP Multipath . . . . . . . . . . . . . 21 75 2.12. TCP Behavior Wording . . . . . . . . . . . . . . . . . . 25 76 2.13. Next Hop for Originated Route . . . . . . . . . . . . . . 25 77 2.14. NEXT_HOP to Internal Peer . . . . . . . . . . . . . . . . 26 78 2.15. Grammar Fix . . . . . . . . . . . . . . . . . . . . . . . 26 79 2.16. Need ToC, Glossary and Index . . . . . . . . . . . . . . 27 80 2.17. Add References to other RFC-status BGP docs to base 81 spec . . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 2.18. IP Layer Fragmentation . . . . . . . . . . . . . . . . . 27 83 2.19. Appendix Section 6.2: Processing Messages on a Stream 84 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 28 85 2.20. Wording fix in Section 4.3 . . . . . . . . . . . . . . . 29 86 2.21. Authentication Text Update . . . . . . . . . . . . . . . 29 87 2.22. Scope of Path Attribute Field . . . . . . . . . . . . . . 30 88 2.23. Withdrawn and Updated routes in the same UPDATE message . 31 89 2.24. Addition or Deletion of Path Attributes . . . . . . . . . 32 90 2.25. NEXT_HOP Semantics . . . . . . . . . . . . . . . . . . . 33 91 2.26. Attributes with Multiple Prefixes . . . . . . . . . . . . 34 92 2.27. Allow All Non-Destructive Messages to Refresh Hold 93 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . 34 94 2.28. BGP Identifier as Variable Quantity . . . . . . . . . . . 35 95 2.29. State Why Unresolveable Routes Should Be Kept in 96 Adj-RIB-In . . . . . . . . . . . . . . . . . . . . . . . 35 97 2.30. Mention Other Message Types . . . . . . . . . . . . . . . 36 98 2.31. Add References to Additional Options . . . . . . . . . . 37 99 2.32. Clarify EGP Reference . . . . . . . . . . . . . . . . . . 37 100 2.32.1. EGP ORIGIN Clarification . . . . . . . . . . . . . . 38 101 2.32.2. BGP Destination-based Forwarding Paradigm . . . . . 42 102 2.33. Add "Optional Non-Transitive" to the MED Section . . . . 46 103 2.34. Timer & Counter Definition . . . . . . . . . . . . . . . 46 104 2.35. Fix Typo . . . . . . . . . . . . . . . . . . . . . . . . 47 105 2.36. Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary . 47 106 2.37. Combine "Unfeasible Routes" and "Withdrawn Routes" . . . 47 107 2.38. Clarify Outbound Route Text . . . . . . . . . . . . . . . 49 108 2.39. Redundant Sentence Fragments . . . . . . . . . . . . . . 50 109 2.40. Section 9.2.1.1 - Per Peer vs. Per Router 110 MinRouteAdvertisementInterval . . . . . . . . . . . . . . 51 111 2.41. Mention FSM Internal Timers . . . . . . . . . . . . . . . 51 112 2.42. Delete the FSM Section . . . . . . . . . . . . . . . . . 52 113 2.43. Clarify the NOTIFICATION Section . . . . . . . . . . . . 52 114 2.44. Section 6.2: OPEN message error handling . . . . . . . . 53 115 2.45. Consistent References to BGP Peers/Connections/Sessions . 55 116 2.46. FSM Connection Collision Detection . . . . . . . . . . . 56 117 2.47. FSM - Add Explicit State Change Wording . . . . . . . . . 58 118 2.48. Explicitly Define Processing of Incoming Connections . . 58 119 2.49. Explicitly Define Event Generation . . . . . . . . . . . 62 120 2.50. FSM Timers . . . . . . . . . . . . . . . . . . . . . . . 63 121 2.51. FSM ConnectRetryCnt . . . . . . . . . . . . . . . . . . . 63 122 2.52. Section 3: Keeping routes in Adj-RIB-In . . . . . . . . . 64 123 2.53. Section 4.3 - Routes v. Destinations - Advertise . . . . 65 124 2.54. Section 4.3 - Routes v. Destinations - Withdraw . . . . . 66 125 2.55. Section 4.3 - Description of AS_PATH length . . . . . . . 68 126 2.56. Section 6 - BGP Error Handling . . . . . . . . . . . . . 69 127 2.57. Section 6.2 - Hold timer as Zero . . . . . . . . . . . . 71 128 2.58. Deprecation of ATOMIC_AGGREGATE . . . . . . . . . . . . . 72 129 2.59. Section 4.3 - Move text . . . . . . . . . . . . . . . . . 80 130 2.60. Section 4.3 - Path Attributes . . . . . . . . . . . . . . 81 131 2.61. Next Hop for Redistributed Routes . . . . . . . . . . . . 82 132 2.62. Deprecate BGP Authentication Optional Parameter from 133 RFC1771 . . . . . . . . . . . . . . . . . . . . . . . . . 84 134 2.63. Clarify MED Removal Text . . . . . . . . . . . . . . . . 88 135 2.64. MED for Originated Routes . . . . . . . . . . . . . . . . 93 136 2.65. Rules for Aggregating with MED and NEXT_HOP . . . . . . . 94 137 2.66. Complex AS Path Aggregating . . . . . . . . . . . . . . . 95 138 2.67. Counting AS_SET/AS_CONFED_* . . . . . . . . . . . . . . . 97 139 2.68. Outbound Loop Detection . . . . . . . . . . . . . . . . . 98 140 2.69. Appendix A - Other Documents . . . . . . . . . . . . . . 99 141 3. The Issues from -18 to -19 . . . . . . . . . . . . . . . . . 100 142 3.1. Reference to RFC 1772 . . . . . . . . . . . . . . . . . . 100 143 3.2. MUST/SHOULD Capitalization . . . . . . . . . . . . . . . 100 144 3.3. Fix Update Error Subcode 7 -- accidently removed . . . . 101 145 3.4. Section 5.1.4 - Editorial Comment . . . . . . . . . . . . 101 146 3.5. Section 9.1 - Change "all peers" to "peers" . . . . . . . 102 147 3.6. AS Loop Detection & Implicit Withdraws . . . . . . . . . 102 148 3.7. Standardize FSM Timer Descriptions . . . . . . . . . . . 103 149 3.8. FSM MIB enumerations . . . . . . . . . . . . . . . . . . 104 150 3.9. Make "delete routes" language consistent . . . . . . . . 104 151 3.10. Correct OpenSent and OpenConfirm delete wording . . . . . 105 152 3.11. Incorrect next state when the delay open timer expires . 105 153 3.12. Entering OpenConfirm / Adding "Stop OpenDelay" action . . 106 154 3.13. FSM Missing Next States . . . . . . . . . . . . . . . . . 110 155 3.13.1. FSM Missing Next States - Event 15 or 16 (Connect 156 State) . . . . . . . . . . . . . . . . . . . . . . . 111 157 3.13.2. FSM Missing Next States - Event 14 (Connect State) . 112 158 3.13.3. FSM Missing Next States - Event 15 or 16 (Active 159 State) . . . . . . . . . . . . . . . . . . . . . . . 114 160 3.13.4. FSM Missing Next States - Event 13-17 (TCP 161 Connection) . . . . . . . . . . . . . . . . . . . . 114 162 3.13.5. FSM Missing Next States - Event 17 (Connect State) . 116 163 3.13.6. FSM Missing Next States - Event 18 (Open Confirm) . 118 164 3.14. FSM - Peer Oscillation Damping . . . . . . . . . . . . . 120 165 3.15. FSM - Consistent FSM Event Names . . . . . . . . . . . . 121 166 3.16. Many Editorial Comments . . . . . . . . . . . . . . . . . 123 167 3.17. Section 3, Page 8, Paragraph 3 - Obsolete? . . . . . . . 127 168 3.18. MED Removal Text . . . . . . . . . . . . . . . . . . . . 130 169 3.19. Security Considerations . . . . . . . . . . . . . . . . . 133 170 3.20. Peer Oscillation Damping . . . . . . . . . . . . . . . . 133 171 3.21. Session Attributes - IdleHold Timer . . . . . . . . . . . 134 172 3.22. Specify New Attributes (Accept Connections/Peer 173 Oscillation Damping) . . . . . . . . . . . . . . . . . . 135 174 3.23. Event1/Event2 Clean Up . . . . . . . . . . . . . . . . . 136 175 3.24. Events 3, 5, 6 & 7 Give Examples . . . . . . . . . . . . 137 176 3.25. Event 4 & 5 Session Initiation Text . . . . . . . . . . . 138 177 3.26. Event 4 & 5 - bgp_stop_flap option . . . . . . . . . . . 139 178 3.27. Event 5 Clarification . . . . . . . . . . . . . . . . . . 141 179 3.28. Timer Events Definition - Make Consistent . . . . . . . . 141 180 3.29. Event 8 - Clean Up . . . . . . . . . . . . . . . . . . . 142 181 3.30. Hold Timer - Split? . . . . . . . . . . . . . . . . . . . 142 182 3.31. OpenDelay Timer Definition . . . . . . . . . . . . . . . 143 183 3.32. Definition of TCP Connection Accept (Event 13) . . . . . 143 184 3.33. Event 13 & 14 - Valid Addresses & Ports . . . . . . . . . 144 185 3.34. Event 17 - TCP Connection Fails to TCP Connection 186 Termination . . . . . . . . . . . . . . . . . . . . . . . 144 187 3.35. Making Definition Style Consistent . . . . . . . . . . . 145 188 3.36. Event 19 - Definition Cleanup . . . . . . . . . . . . . . 147 189 3.37. Event 22 - Cleanup . . . . . . . . . . . . . . . . . . . 148 190 3.38. FSM Description - ConnectRetry Count . . . . . . . . . . 149 191 3.39. Handling Event 7 (Auto Stop) to Idle State processing . . 149 192 3.40. Clearing the Connection Retry Timer . . . . . . . . . . . 150 193 3.41. Handling of Event 14 in the Connect State . . . . . . . . 151 194 3.42. Handling events 20, 21 in the Connect State and Active 195 State . . . . . . . . . . . . . . . . . . . . . . . . . . 152 196 3.43. Handling the default events in the Connect state . . . . 155 197 3.44. Handling Event 23 in Connect and OpenSent . . . . . . . . 156 198 3.45. Event 17 in the Connect state . . . . . . . . . . . . . . 158 199 3.46. Handling of Event 17 in Active state . . . . . . . . . . 161 200 3.47. Handling of Event 19 in Active state . . . . . . . . . . 161 201 3.48. Handling of Event 2 in Active state . . . . . . . . . . . 162 202 3.49. Default Event handling in Active state . . . . . . . . . 163 203 3.50. Clearing Hold timer in OpenSent, OpenConfirm and 204 Established State . . . . . . . . . . . . . . . . . . . . 164 205 3.51. Clearing Keepalive timer in OpenConfirm and 206 Established State . . . . . . . . . . . . . . . . . . . . 164 207 3.52. Handling Event 18 in the OpenSent state (Keepalive 208 Timer) . . . . . . . . . . . . . . . . . . . . . . . . . 165 209 3.53. Established State MIB . . . . . . . . . . . . . . . . . . 167 210 3.54. State impact of not supporting Optional Events . . . . . 168 211 3.55. New DelayOpen State . . . . . . . . . . . . . . . . . . . 169 212 3.56. Clarify what is covered in the base document . . . . . . 169 213 4. Security Considerations . . . . . . . . . . . . . . . . . . . 170 214 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 170 215 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 170 216 6.1. Normative References . . . . . . . . . . . . . . . . . . 170 217 6.2. Informative References . . . . . . . . . . . . . . . . . 170 218 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 171 220 1. Introduction 222 This document records the issues discussed and the consensus reached 223 in the Interdomain Routing (IDR) Working Group during its efforts to 224 revise and bring up to date the base specification for the BGP-4 225 protocol as documented in RFC1771. The results of these efforts are 226 encoded in RFC4271. The rational for doing this is simple: 227 Experience has demonstrated that the same issues and questions tend 228 to come up again and again. This memo will document not only the 229 decisions on these issues but also how and why the working group 230 reached those conclusions. We hope that this will help make future 231 discussions more fruitful by providing them with a historical 232 context. 234 This document traces the evolution of the BGP-4 base specification 235 from its incarnation as draft-ietf-idr-bgp4-17.txt through the big 236 revision and update push culminating in draft-ietf-idr-bgp4-19.txt. 237 It is divided into two main sections. The first deals with the 238 issues discussed between -17 and -18, and the second deals with the 239 issues discussed between -18 and -19. 241 N.B. There is no rhyme or reason to the numbering scheme other than 242 unique tags to address the issues. 244 2. The Issues from -17 to -18 246 This section lists the issues discussed on the list from late August 247 to late October 2002. 249 2.1. IDR WG Charter 251 Status: Consensus 252 Change: Yes 253 Summary: New charter adopted. 255 Discussion: 257 A variety of discussions surrounded the new charter. The rough 258 consensus is to accept the new charter that the AD's have proposed, 259 and to push as hard a possible to get the base spec to RFC status so 260 other drafts that are dependent can also move forward. 262 For our information, Alex has provided these approximate time lines: 264 Stage Anticipated delay Comment 265 -------------------------------------------------------------------- 266 AD-review 1-4 weeks The document may go back depending on to the WG 267 for the workload AD-review comments to be addressed; this would 268 introduce additional delay. 270 IETF LC 2 weeks Same as above 272 IESG review & 1-2 weeks depending Same as above telechat on when the 273 IETF LC ends 274 -------------------------------------------------------------------- 276 Note that if the document is sent back to the WG at some stage, 277 required changes may warrant an additional WG Last Call. 279 I can personally commit to a 2-week upper bound for the AD-review 280 period. Bill may have a different timer granularity. 282 The opinions expressed on this were 7 in favor, 4 against. 284 This thread has messages subjects of "BGP spec and IDR WG charter" 285 and "IDR WG charter". 287 2.2. TCP Port 289 Status: Consensus 290 Change: Yes 291 Summary: 293 Change: 294 "BGP uses TCP port 179 for establishing its connections." 296 To: 297 "BGP listens on TCP port 179." 299 Discussion: 301 There has been a discussion on clarifying the wording in Section 2, 302 on which port BGP uses. The original text was: 304 "BGP uses TCP port 179 for establishing its connections." 306 The proposed new text is: 308 "BGP listens on TCP port 179." 310 There seems to be a rough consensus that the new text is better. 312 This thread has a message subject of "Review: Section 2, TCP Port 313 179" 315 2.3. FSM wording for what state BGP accepts connections in 317 Status: Consensus 318 Change: No 319 Summary: No change necessary 321 Discussion: 323 An issue was brought up later in the "Review: Section 2, TCP Port 324 179" thread about the words in the FSM for what state BGP accepts 325 connections in. The consensus is that the existing wording is clear. 327 2.4. BGP Identifier/Router ID 329 Status: Consensus 330 Change: No 331 Summary: No change necessary to base draft. Perhaps in a BCP. 333 Discussion: 335 The "admin dist/gp spec proposal", "Router ID" and "bgp spec 336 proposal" threads discussed the BGP Identifier and how close or not 337 it is to IGP's Router ID. The consensus was that this discussion is 338 better saved for a BCP draft, and that it does not need to be 339 contained in the base spec. 341 2.5. Direct EBGP Peers 343 Status: Consensus Change: No Summary: A recollection that ebgp peers 344 must be direct. No text proposed, no discussion. 346 Discussion: 348 Jonathan recalled something that stated that ebgp peers must be 349 direct. No specific sections were quoted. 351 Yakov responded to this with: 353 Section 5.1.3 talks about both the case where ebgp peers are 1 IP hop 354 away from each other: 356 2) When sending a message to an external peer X, and the peer is one 357 IP hop away from the speaker: 359 as well as the case where they are multiple IP hops away from each 360 other: 362 3) When sending a message to an external peer X, and the peer is 363 multiple IP hops away from the speaker (aka "multi hop EBGP"): 365 And emphasized that multi hop EBGP does exist. 367 This came up in the "bgp draft review" thread. 369 2.6. Disallow Private Addresses 371 Status: Consensus 372 Change: No 373 Summary: No change necessary 375 Discussion: 377 In the thread entitled "bgp draft review": 379 Mentioned explicitly disallowing private addresses. The consensus 380 was that there is no reason to disallow them. Which IP addresses 381 peers use is an operational issue. 383 2.7. Renumber Appendix Sections 385 Status: Consensus 386 Change: Yes 387 Summary: Rename/renumber appendix sections so they do not have the 388 same numbers as sections of the main text. 390 Discussion: 392 In the tread entitled "bgp draft review": 394 This thread brought up renaming sections in the appendix to avoid 395 confusion with sections of the same number in the main text. 397 Yakov responded that he would do so in the next edition. 399 2.8. Jitter Text 401 Status: Consensus 402 Change: Yes 403 Summary: 405 Get rid of section 9.2.1.3 ("Jitter"). Move the text to an 406 Appendix: "BGP Timers" Expand text to indicate that jitter applies 407 to all timers, including ConnectRetry. 409 The text for the appendix is listed at the end of the discussion. 411 Discussion: 413 In the tread entitled "bgp draft review": The thread also proposed: 415 "jitter should be applied to the timers associated with 416 MinASOriginationInterval, Keepalive, and 417 MinRouteAdvertisementInterval" 419 Be changed to: 421 "jitter should be applied to the timers associated with ConnectRetry 422 timer" 424 Yakov agreed with making some changes and suggested that we make sure 425 that jitter is applied to all timers. Specifically, he proposes we 426 get rid of section 9.2.1.3 ("Jitter"), move the text of this section 427 into Appendix "BGP Timers", and expand the text to indicate that 428 jitter applies to ConnectRetry timer as well. 430 Jonathan, the original commenter, agreed with Yakov's suggestion. 432 In a follow-up to this issue, there was a question raised about the 433 values we have specified for timers in the document. Specifically: 435 The ConnectRetry timer is should have a value that is 'sufficiently 436 large to allow TCP initialization. Application of jitter can reduce 437 the this value (by up to 25%). A configuration which the 438 ConnectRetry timer has been pegged at a value close to TCP connection 439 time may cause a connection to be terminated as a result of this 440 jitter. Is this a cause for concern ? 442 The default value suggested for ConnectRetry (120 seconds) is 443 sufficiently large that event with a jitter of 0.75, it will be 444 greater than TCP's connection establishment timer. 446 Is adding a jitter to the ConnectRetry timer a standard practice ? 447 What benefit does this provide ? 449 Curtis responded to this with: 451 The TCP connection establishment timer is 75 seconds (sysctl yield 452 "net.inet.tcp.keepinit: 75000" in BSD-oids). 454 The ConnectRetry determines when to make a second attempt after a 455 prior attempt to connect has failed. It is to avoid a rapid 456 succession of retries on immediate failures (for example "Connection 457 refused" if the peer was in the middle of a reboot, Network 458 Unreachable if you can't get there from here, etc) but also covers 459 the case where the TCP SYN goes off and is never heard from again. 461 And Jonathan replied with this information about current practice: 463 It seems to me that if you bring up all bgp peers at once it may lead 464 to load spikes on the network. Cisco seems to wait 27.5 +/- 2.5 465 seconds for IBGP, and 40 +/- 5 seconds for EBGP--20 sec. from config 466 time to the "open active, delay" jittered delay assignment plus the 467 jittered delay (5 to 10 sec. for IBGP, and 15 to 25 sec. for EBGP). 468 This would also apply for "no neighbor x.x.x.x shutdown". Their 469 value of ConnectRetry is 60sec. though, not sure how this value is 470 used (based on above). Maybe some Cisco folks can chime in on this 471 one??? 473 I did not check Juniper. 475 Also, interestingly, they do not apply jitter to the other timers (as 476 far as I can tell), but I don't see a problem with this. 478 Another timer that they use that is not mentioned in the draft/rfc is 479 the next hop resolution timer which is 30 seconds. Although it would 480 be nice to have this in the spec, I will concede that it is out of 481 scope and/or implementation dependent. 483 So the question that arises from this followup, is how does this 484 question affect the text of the appendix on jitter? 486 Curtis replied that we need to only state that jitter should be 487 applied to all timers. Whether a vendor does so or not is a minor 488 deficiency and does not bear on interoperability. Therefore, 489 specifying exact details are not necessary. 491 After Jonathan's response Curtis and Jonathan agreed that jitter 492 should be added to all timers and that we should state so in the 493 text. 495 Yakov proposed the following text for the appendix to discuss jitter: 497 I'd like to propose the following text for "BGP Timers" section: 499 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 500 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 501 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 502 9.2.1.1). 504 The suggested value for the ConnectRetry timer is 120 seconds. 506 The suggested value for the Hold Time is 90 seconds. 508 The suggested value for the KeepAlive timer is 1/3 of the Hold Time. 510 The suggested value for the MinASOriginationInterval is 15 seconds. 512 The suggested value for the MinRouteAdvertisementInterval is 30 513 seconds. 515 An implementation of BGP MUST allow the Hold Time timer to be 516 configurable, and MAY allow the other timers to be configurable. 518 To minimize the likelihood that the distribution of BGP messages by a 519 given BGP speaker will contain peaks, jitter should be applied to the 520 timers associated with MinASOriginationInterval, Keepalive, 521 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 522 shall apply the same jitter to each of these quantities regardless of 523 the destinations to which the updates are being sent; that is, jitter 524 will not be applied on a "per peer" basis. 526 The amount of jitter to be introduced shall be determined by 527 multiplying the base value of the appropriate timer by a random 528 factor which is uniformly distributed in the range from 0.75 to 1.0. 530 Jeff & Ben agreed with this. 532 Justin suggested that we move the range from 0.75 to 1.25 to ensure 533 that the average is around the configured value. Yakov agreed with 534 Justin's changes. Jonathan disagreed, arguing that it was out-of- 535 scope for the task of clarifying the text only. Justin agreed and 536 withdrew his comment. 538 Curtis liked the general text, but suggested these modifications: 540 minor improvement (not really an objection) -- s/suggested value/ 541 suggested default value/g 543 Also 545 s/shall apply the same jitter/may apply the same jitter/ (to each of 546 these quantities regardless of ...). 548 s/jitter will not be applied/jitter need not be configured/ (on a 549 "per peer" basis). 551 He stated that in Avici's implementation they allow a lot of 552 granularity in timer settings, so this reflects current practice. 554 Curtis also suggested changing the last paragraph: 556 The suggested default amount of jitter shall be determined by 557 multiplying the base value of the appropriate timer by a random 558 factor which is uniformly distributed in the range from 0.75 to 1.0. 559 A new random value should be picked each time the timer is set. The 560 range of the jitter random value MAY be configurable. 562 This would make it clear that it is possible to have this timer as 563 configurable and still be within spec. 565 Other comments on Yakov's text pointed out that IOS uses 5 seconds as 566 the default IBGP MinRouteAdvertisementInterval. 568 Tom pointed out that there seems to be a discrepancy between this 569 text and the FSM: The FSM has an OpenDelay timer. And the FSM 570 suggests a HoldTimer of 4 minutes. 572 In following up on this issue, Yakov stated: 574 Here is the final text for the BGP Timers section: 576 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 577 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 578 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 579 9.2.1.1). 581 The suggested default value for the ConnectRetry timer is 120 582 seconds. 584 The suggested default value for the Hold Time is 90 seconds. 586 The suggested default value for the KeepAlive timer is 1/3 of the 587 Hold Time. 589 The suggested default value for the MinASOriginationInterval is 15 590 seconds. 592 The suggested default value for the MinRouteAdvertisementInterval is 593 30 seconds. 595 An implementation of BGP MUST allow the Hold Time timer to be 596 configurable, and MAY allow the other timers to be configurable. 598 To minimize the likelihood that the distribution of BGP messages by a 599 given BGP speaker will contain peaks, jitter should be applied to the 600 timers associated with MinASOriginationInterval, Keepalive, 601 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 602 may apply the same jitter to each of these quantities regardless of 603 the destinations to which the updates are being sent; that is, jitter 604 need not be configured on a "per peer" basis. 606 The suggested default amount of jitter shall be determined by 607 multiplying the base value of the appropriate timer by a random 608 factor which is uniformly distributed in the range from 0.75 to 1.0. 609 A new random value should be picked each time the timer is set. The 610 range of the jitter random value MAY be configurable. 612 With this in mind, I would suggest we mark this issue as closed. 614 Jonathan suggested adding "per peer" to the text, Yakov responded 615 with this text: 617 An implementation of BGP MUST allow the Hold Time timer to be 618 configurable on a per peer basis, and MAY allow the other timers to 619 be configurable. 621 This proposal met with general agreement. This issue is at 622 consensus. 624 2.9. Reference to RFC904 - EGP Protocol 626 Status: Consensus 627 Change: Yes 628 Summary: Add a reference to RFC904 630 Discussion: 632 The "Review Comment: Origin Attribute pg 14" thread suggested adding 633 a reference to RFC904(?), to refer to the EGP protocol. There was no 634 discussion. 636 Yakov agreed to this, and Jonathan seconded it. 638 2.10. Extending AS_PATH Attribute 640 Status: Consensus 641 Change: Yes 642 Summary: Add this to 9.2: 644 If due to the limits on the maximum size of an UPDATE message (see 645 Section 4) a single route doesn't fit into the message, the BGP 646 speaker MUST NOT advertise the route to its peers and may choose to 647 log an error locally. 649 Discussion: 651 The "Extending AS_PATH attribute length en route" thread brought up 652 the issue of what action should we specify when we receive a route 653 with an AS_PATH that exceeds the defined maximum length. There was 654 some discussion, and it was suggested that, after logging the error, 655 the route not be propagated. 657 Yakov stated that: 659 The real issue here is how to handle the case when a route (a single 660 address prefix + path attributes) doesn't fit into 4K bytes (as the 661 max BGP message size is 4 K). To address this issue I would suggest 662 to add the following to 9.2: 664 After some discussion, Yakov's proposed text's last sentence was 665 dropped and we arrived at: 667 If due to the limits on the maximum size of an UPDATE message (see 668 Section 4) a single route doesn't fit into the message, the BGP 669 speaker may choose not to advertise the route to its peers. 671 In response to Andrew's clarification question to the list, Curtis 672 responded: 674 Wording would be more like: 676 If the attributes for a specific prefix becomes too large to fit the 677 prefix into the maximum sized BGP UPDATE message, the prefix should 678 not be advertised further. Truncation or omission of attributes 679 should not occur unless policies for such modifications are 680 specifically configured. Such policies may contribute to the 681 formation of route loops and are not within the scope of this 682 protocol specification. 684 After some additional discussion, it was decided that we add "and may 685 choose to log an error locally." to the end of Yakov's text. 687 Also, we agreed to change "may choose not to advertise..." to "MUST 688 NOT advertise...". 690 So the text on the table right now is: 692 If due to the limits on the maximum size of an UPDATE message (see 693 Section 4) a single route doesn't fit into the message, the BGP 694 speaker MUST NOT advertise the route to its peers and may choose to 695 log an error locally. 697 This met with one agreement and no disagreements. We have a 698 consensus. 700 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 702 Status: Consensus 703 Change: Yes 704 Summary: Add this text: 706 The local speaker SHALL then install that route in the Loc-RIB, 707 replacing any route to the same destination that is currently being 708 held in the Loc-RIB. When the new BGP route is installed in the 709 Rout- ing Table, care must be taken to ensure that existing routes to 710 the same destination that are now considered invalid are removed from 711 the Routing Table. Whether or not the new BGP route replaces an 712 existing non-BGP route in the Routing Table depends on the policy 713 configured on the BGP speaker. 715 Discussion: 717 The "Proxy: comments on section 9.1.3" thread brought up some lack of 718 clarity in the section discussing the rules for which routes get 719 propagated from the Loc-RIB into the Adj-RIB-Out. These discussions 720 resulted in a number of suggestions for new text. 722 The first new text was proposed to clarify the issue that the thread 723 first brought up: 725 I agree that this could use some clarification. How about adding to 726 b) in section 9.1: 728 The Loc-RIB must contain only one route per destination; further, it 729 must include all routes that the BGP speaker is using. 731 changing c) in section 9.1.2 to: 733 c) is selected as a result of the Phase 2 tie breaking rules 734 specified in 9.1.2.2, or 736 and adding 738 d) when routing protocols other than BGP are in use, is determined by 739 some other local means to be the route that will actually be used to 740 reach a particular destination. 742 This text was never discussed or a consensus formed on putting it in 743 the document. 745 This modification to 9.1.2 was also proposed to address the same 746 concern: 748 How about changing the paragraph after c) in 9.1.2 to: 750 The local speaker SHALL then install that route in the Loc-RIB, 751 replacing any route to the same destination that is currently being 752 held in the Loc-RIB. This route SHALL then also be installed in the 753 BGP speakers forwarding table. 755 There was one response in the negative to this change, arguing that 756 is is not necessary. 758 Yakov replied to this that: 760 Wrt "adding to b) in section 9.1", the second part (after ";") is 761 redundant as this point is already stated in 3.2. Wrt the first 762 point about Loc-RIB containing just one route per destination, I 763 would suggest to add it to section 3.2, where Loc-RIB is first 764 introduced, rather than adding it to 9.1. 766 Wrt "changing c)... and adding...", I have no objections to add/ 767 modify the text, as suggested above. 769 I am not sure though that changing the paragraph after c) in 9.1.2 is 770 really necessary though, so I would prefer to keep it as is. 772 The "issue 11" thread this was being discussed in then digressed to 773 the topic, now covered in issue 11.3. 775 Ben re-addressed the original issue with this input: 777 I have somewhat of an issue with the paragraph after item c section 778 9.1.2 as discussed. 780 which is => 782 "The local speaker SHALL then install that route in the Loc-RIB, 783 replacing any route to the same destination that is currently being 784 held in the Loc-RIB. If the new BGP route is installed in the 785 Routing Table (as a result of the local policy decision), care must 786 be taken to ensure that invalid BGP routes to the same destination 787 are removed from the Routing Table. Whether or not the new route 788 replaces an already existing non-BGP route in the routing table 789 depends on the policy configured on the BGP speaker." 791 Can we assume that its OK to have a route present in the Loc-RIB and 792 possibly in the adj-RIB-Out but not in the Routing table due to some 793 policy. Won't we violate rule number 1? Only advertise what you 794 use. 796 As conversely implied in this sentence => 798 "If the new BGP route is installed in the Routing Table (as a result 799 of the local policy decision), care must be taken to ensure that 800 invalid BGP routes to the same destination are removed from the 801 Routing Table" 803 I would rephrase the paragraph as follows => 805 "The local speaker SHALL then install that route in the Loc-RIB, 806 replacing any route to the same destination that is currently being 807 held in the Loc-RIB. When the new BGP route is installed in the 808 Routing Table, care must be taken to ensure that existing routes to 809 the same destination that are now considered invalid are removed from 810 the Routing Table. Whether or not the new BGP route replaces an 811 existing non-BGP route in the routing table depends on the policy 812 configured on the BGP speaker." 814 Jeff replied: 816 With the exception that Routing Table should be capitalized 817 throughout, I'd suggest we take this as consensus. 819 Yakov agreed. We are at consensus. 821 2.11.1. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3 823 Status: Consensus 824 Change: Yes 825 Summary: The text below will be added to the -18 version. 827 Discussion: 829 In further discussions around this issue, this text was also 830 proposed: 832 How about adding to section 9.1.3, at the end: 834 Any local-policy which results in reachability being added to an Adj- 835 RIB-Out without also being added to the local BGP speaker's 836 forwarding table is beyond the scope of this document. 838 This suggestion received one response that agreed to this change. 840 This text will be added to the -18 version, and since there were no 841 objections, this issue has been moved to consensus. 843 2.11.2. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2 845 Status: Consensus 846 Change: Yes 847 Summary: Add this text: 849 In the context of this document we assume that a BGP speaker 850 advertises to its peers only those routes that it itself uses (in 851 this context a BGP speaker is said to "use" a BGP route if it is the 852 most preferred BGP route and is used in forwarding). All other cases 853 are outside the scope of this document. 855 Discussion: 857 Additionally this thread produced this section of new text, in 858 section 2: 860 862 "one must focus on the rule that a BGP speaker advertises to its 863 peers (other BGP speakers which it communicates with) in neighboring 864 ASs only those routes that it itself uses." 866 Should be changed to 868 870 "one must focus on the rule that a BGP speaker advertises to its 871 peers (other BGP speakers which it communicates with) in neighboring 872 ASs only routes whose NLRIs are locally reachable." 874 876 "one must focus on the rule that a BGP speaker advertises to its 877 peers (other BGP speakers which it communicates with) in neighboring 878 ASs only routes which are locally reachable. Local reachability can 879 be achieved by having any protocol route to the given destination in 880 the routing table." 882 There were a lot of emails exchanged on this topic with a variety of 883 texts proposed (see early in the "Active Route" thread). This issue 884 reopened with Jonathan, who brought up the issue originally, stating 885 that: 887 The issue I raised, and would like to be [re-]considered is with: 889 "one must focus on the rule that a BGP speaker advertises to its 890 peers (other BGP speakers which it communicates with) in neighboring 891 ASs only those routes that it itself uses." 893 Curtis replied that: 895 That is called route origination and it is allowed by: 897 9.4 Originating BGP routes 899 A BGP speaker may originate BGP routes by injecting routing 900 information acquired by some other means (e.g. via an IGP) into BGP. 901 [...] The decision whether to distribute non-BGP acquired routes 902 within an AS via BGP or not depends on the environment within the AS 903 (e.g. type of IGP) and should be controlled via configuration. 905 Advice on what to put in the AS_PATH and NEXT_HOP is in the document. 907 He continued with: 909 I don't think there was ever consensus on what to do with the 910 statement "a BGP speaker advertises to its peers (other BGP speakers 911 which it communicates with) in neighboring ASs only those routes that 912 it itself uses". Some reasonable choices are: 914 1. Omit it (the implied consensus of the rewrite of the paragraph in 915 32.2). 917 2. Leave it as is and put it in another paragraph to separate it 918 from the destination based routing statement. 920 3. Clean up the wording and put it in another paragraph to separate 921 it from the destination based routing statement. 923 The separate paragraph for 2 would be the exact sentence we now have. 925 A BGP speaker advertises to its peers (other BGP speakers which it 926 communicates with) in neighboring ASs only those routes that it 927 itself uses. 929 In possibility 3 we (try to) clear up the ambiguity about the meaning 930 of the word "use" in this sentence. 932 A BGP speaker advertises to its peers (other BGP speakers which it 933 communicates with) in neighboring ASs only those routes that it 934 itself uses. In this context a BGP speaker is said to "use" a BGP 935 route if it is the most preferred BGP route and is either directly 936 used in forwarding or in a specifically configured case where the BGP 937 route would be forwarded internally but IGP forwarding information is 938 used. The latter case reflects a usage in which the IGP is used for 939 forwarding but BGP is originated to IBGP to carry attributes that 940 cannot be carried by the IGP (for example, BGP communities [N]). 941 Other special cases such as virtual routers and multiple instances of 942 BGP on a single router are beyond the scope of this document but for 943 each of these the statement "a BGP speaker advertises to its peers 944 (other BGP speakers which it communicates with) in neighboring ASs 945 only those routes that it itself uses" can (and should in the 946 definition of the extension) be made true with an appropriate 947 definition of the word "use". 949 Unless someone volunteers better wording this may be a good starting 950 point. I thing the last sentence borders on ridiculous in a protocol 951 spec but may be necessary to address specific objections raised on 952 this mailing list. If we want to elaborate on the meaning of the 953 word "use" and address the objections this is what we end up with. 955 Of course looking at what we ended up with, I'd also go along with 956 the other two options (leave it out or put the one sentence in a 957 separate paragraph as is). 959 After some additional discussion (in the "issue 11.2" thread), we 960 have come to a consensus on this text: 962 In the context of this document we assume that a BGP speaker 963 advertises to its peers only those routes that it itself uses (in 964 this context a BGP speaker is said to "use" a BGP route if it is the 965 most preferred BGP route and is used in forwarding). All other cases 966 are outside the scope of this document. 968 This issue is at consensus. 970 2.11.3. Documenting IBGP Multipath 972 Status: Consensus 973 Change: Yes 974 Summary: The documenting of IBGP Multipath is left to another 975 Internet Draft. The consensus is that it should not be in the base 976 spec. 978 Discussion: 980 This thread began in the "issue 11" discussion. In it it was 981 proposed that: 983 There is support in some router vendors to allow more than one BGP 984 route to be installed, for the purpose for load balancing. Given 985 that this is a current practice, and seems to be a useful feature as 986 well, should we insist that only one route be installed in the Loc- 987 RIB ? 989 I would like to suggest that all sections which use MUST in the 990 context of only one route in Loc-RIB be relaxed a little to a SHOULD, 991 and a section added that states that it is possible for a n 992 implementation to add more than one route to the Loc-RIB for the 993 purposes of load balancing. 995 While it will be useful to describe how this situation is the 996 handler, it is perhaps sufficient to even state that handling of this 997 situation is outside the scope of this RFC. 999 I am including some proposed text for this purpose: 1001 For the part: 1003 > The Loc-RIB must contain only one route per destination; 1005 consider instead, 1007 % The Loc-RIB SHOULD contain only one route per destination. % An 1008 implementation may choose to install multiple routes to % a 1009 destination (for the purposes of load balancing). The % handling of 1010 such a configuration, however, is outside the % scope of this RFC. 1012 Perhaps, this can be in section 3.2 instead. 1014 After much discussion back and forth, it was agreed that documenting 1015 IBGP Multipath behavior is a good thing. However, it is something 1016 that belongs in another draft. 1018 Alex opened this issue up again. There were a flurry of responses, 1019 most all of them agreeing with the original consensus that we should 1020 document this feature in a different draft, since it doesn't affect 1021 the core interoperability requirements, and we want to advance the 1022 spec in a timely manner. 1024 Alex persisted in his assertion that this belongs in the base 1025 specification. Right now, the issue is still open. 1027 This discussion later expanded in scope to include all BGP multipath. 1029 Curtis laid out a good description of the various flavors of 1030 multipath: 1032 In addition to IGP multihop, there are two cases of BGP multipath. 1034 In IGP multihop there is one BGP advertisement but to ways to reach 1035 th BGP NEXT_HOP via the IGP. 1037 In one case of BGP multihop, two (or more) IBGP routers peering with 1038 the same external AS have equal routes to a destination and are an 1039 equal cost away from a third router. BGP multihop is applicable to 1040 that third router. Without BGP multihop, BGP would normally pick the 1041 BGP NEXT_HOP of the advertisement from only one of those IBGP peers 1042 (using BGP Identifier) and use that. The IGP lookup would yield one 1043 next hop. With BGP multihop, BGP uses the BGP NEXT_HOP of both 1044 advertisements. Each BGP NEXT_HOP has a different IGP next hop (one 1045 or more IGP next hop). 1047 The second case is where all of the candidates routes for BGP 1048 multipath are external. Seldom does IGP multipath come into play for 1049 EBGP (odd tunneled EBGP multihop cases maybe). Typically the load is 1050 split among two (or more) routers in the same AS. 1052 If in EBGP multipath you split among routers in difference AS, an 1053 aggregate should be formed. This is still prior to the IGP cost rule 1054 in the route selection. 1056 Normally one would not combine IBGP and EBGP in multihop given that 1057 the decision point for multihop is after "d" in 9.1.2.2. If the 1058 multihop decision was prior to "d", then two routers each with an 1059 external peering would forward some of the traffic to each other and 1060 for some src/dst pairs, they'd form a loop. [So don't do that!] 1062 This is getting to be a lot to add to the base spec. I hope we've 1063 convinced you that we should put it in another document. 1065 Curtis later added specific text, that could serve as a start for the 1066 new document (or added to the base spec if the consensus ended up 1067 going the other way): 1069 BGP specifies how to select the single best route. OSPF specifically 1070 defines procedures for handling equal cost multipath (ECMP) [cite 1071 OSPF]. The same technique has been applied to ISIS. A similar 1072 technique has been used with BGP. Variations exist but the decision 1073 to support BGP multipath, the specific variation of BGP multipath, or 1074 not to support it, does not affect interoperability. 1076 A naive implementations of ECMP can cause severe performance 1077 degradation for TCP flows. To avoid this, implementations of BGP 1078 multipath SHOULD maintain packet ordering within microflows as 1079 described in [cite rfc2991, rfc2992]. 1081 BGP multipath, if implemented, SHOULD be disabled by default. 1083 In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there 1084 are two variations of BGP multipath described here. A BGP 1085 implementation may offer both, either one, or neither variation of 1086 BGP multipath. Other variations of BGP multipath may exist, but no 1087 guarantees can be made in this protocol specification of their 1088 properties or impact on interoperability. 1090 Where IGP multipath is used, there is an interaction with BGP learned 1091 routes. The lookup of a BGP NEXT_HOP in the IGP can result in the 1092 selection of an IGP multipath entry. This is not a variation of BGP 1093 multipath. When this occurs, one BGP route is selected as the best 1094 but there is more than one way to reach the BGP NEXT_HOP via the IGP. 1096 In one variation of BGP multipath, a set of more than one IBGP 1097 routers peering with the same external AS have equal routes to a 1098 destination and are an equal IGP cost away from a second set of one 1099 or more routers. BGP multipath is applicable to the latter set of 1100 routers. Without BGP multipath, BGP would pick the BGP NEXT_HOP of 1101 the advertisement from only one of those IBGP peers (using BGP 1102 Identifier) and use only that BGP route. With BGP multipath, BGP 1103 uses the BGP NEXT_HOP of more than one of these equal cost 1104 advertisements, yielding more than one BGP NEXT_HOP. Each BGP 1105 NEXT_HOP has a different IGP next hop (one or more IGP next hop if 1106 IGP multipath is in use). 1108 The second case is where all of the candidates routes for BGP 1109 multipath are external and learned by a single BGP peer. Without BGP 1110 multipath this peer would select only one of the BGP routes and 1111 obtain only one BGP NEXT_HOP. With BGP multipath, more than one 1112 equal cost route is selected yielding more than one BGP NEXT_HOP. 1113 Seldom does IGP multipath come into play when looking up an EBGP 1114 NEXT_HOP but could in principle be applicable. 1116 If in EBGP multipath traffic is split among routers in difference AS, 1117 an aggregate SHOULD be formed so as to propagate a route with an 1118 accurate AS_PATH. If the resulting aggregate is not more specific 1119 than the components, the AS_SET SHOULD NOT be dropped. 1121 The decision point for multipath is after step "d" in Section 9.1.2.2 1122 (prefer externally learned routes). IBGP learned and EBGP learned 1123 routes MUST NOT be combined in multipath. If the multipath decision 1124 is prior to "d", then two routers each with an external peering would 1125 form a routing loop. 1127 The decision point for multipath is generally after step "e" in 1128 Section 9.1.2.2. Some relaxation of the "equal cost" rule (also 1129 applicable to IGP multipath) is possible. In addition to the equal 1130 cost BGP NEXT_HOPS available at BGP route selection, if the IGP next 1131 hop for other BGP NEXT_HOPs are of lower cost, then those may be used 1132 as well. This relaxation of the step "e" is possible but is not 1133 widely implemented (and may not be implemented at all). 1135 The consensus of the majority of the IDR WG is to keep this in a 1136 separate draft and out of the base spec. 1138 2.12. TCP Behavior Wording 1140 Status: Consensus 1141 Change: No 1142 Summary: In issue 19 we decided to remove this section entirely. As 1143 a result the previous consensus on this issue (no change) is needed 1144 moot. 1146 Discussion: The subject-less "your mail" thread discussed a wording 1147 clarification from: 1149 "An implementation that would "hang" the routing information process 1150 while trying to read from a peer could set up a message buffer (4096 1151 bytes) per peer and fill it with data as available until a complete 1152 message has been received. " 1154 To something that is more TCP-correct, such as: 1156 "An implementation that would "hang" the routing information process 1157 while trying to received from a peer could set up a message buffer 1158 (4096 bytes) per peer and fill it with data as available until a 1159 complete message has been received. " 1161 (only change: "read" to "received" This was one of a couple of 1162 suggested changes.) 1164 This suggestion was quite contentious, and although there were a 1165 variety of alternate texts proposed, the only consensus was that this 1166 was a very minor issue, and probably not worth changing. 1168 In issue 19 we decided to remove this section entirely. 1170 2.13. Next Hop for Originated Route 1172 Status: Consensus 1173 Change: No 1174 Summary: No responses, assumed consensus to keep things the same. 1176 Discussion: 1178 There was a one-message thread entitled "next hop for originated 1179 route". This message received no response, so the assumption is that 1180 there is a consensus to keep things as they are. 1182 For related discussion see issue 61. 1184 2.14. NEXT_HOP to Internal Peer 1186 Status: Consensus 1187 Change: No 1188 Summary: Closed in favor of issue 61. 1190 Discussion: 1192 The thread entitled "NEXT_HOP to internal peer" starts with this 1193 question: 1195 When sending a locally originated route to an internal peer, what 1196 should NEXT_HOP be set to? 1198 One response suggested that we add a line stating that the NEXT_HOP 1199 address originates from the IGP. 1201 Since this issue and issue 61 are basically the same, except 61 1202 proposes text, we'll close this issue in favor of 61. 1204 2.15. Grammar Fix 1206 Status: Consensus 1207 Change: Yes 1208 Summary: Change: "The Prefix field contains IP address prefixes ..." 1209 To: "contains an IP address prefix ..." 1211 Discussion: The thread entitled "Review comment: bottom of page 16" 1212 corrects a grammar mistake by suggesting we change: 1214 "The Prefix field contains IP address prefixes ..." 1216 to: 1218 "contains an IP address prefix ..." 1220 Yakov responded that this will be fixed in -18. 1222 The consensus seems to be to correct this, and go with the new text. 1224 2.16. Need ToC, Glossary and Index 1226 Status: Consensus 1227 Change: Yes 1228 Summary: Need to add a Table of Contents (ToC), Glossary and Index to 1229 the draft. Will be added in draft -18. 1231 Discussion: 1233 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests: 1235 1. Document needs, Table of Contents, Glossary, and Index 1237 2. Paths, Routes, and Prefixes need to be defined in the spec early 1238 on (like in a glossary), so it is obvious what is implied. 1240 Yakov responded that draft -18 will have a ToC and definition of 1241 commonly used terms. 1243 2.17. Add References to other RFC-status BGP docs to base spec 1245 Status: Consensus 1246 Change: Yes 1247 Summary: Add references to other RFC-status BGP docs to the base 1248 spec. 1250 Discussion: 1252 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes 1253 titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to 1254 suggest: 1256 3. All BGP Extensions described in other documents that made it to 1257 RFC status should be at least referenced in the Reference section 1258 P.64. This is justifiable since it's the core BGP standard spec. 1260 Yakov responded that this will be added to the -18 review. 1262 Jonathan agreed. 1264 2.18. IP Layer Fragmentation 1266 Status: Consensus 1267 Change: No 1268 Summary: No need to mention IP Layer Fragmentation in the BGP 1269 specification, since this is taken care of at the TCP level. 1271 Discussion: 1273 1. P.6 section 4. Message Formats, its possible for the source BGP 1274 peer IP layer to fragment a message such that the receiving BGP peer 1275 socket layer would have to reassemble it. Need to mention this, 1276 since BGP implementations are required to do this. 1278 The response to this was that, while true, reassembly is something 1279 that is inherent in the TCP layer that BGP rides over. Therefore, 1280 this is something that is in the TCP spec, and needn't be repeated in 1281 the BGP spec. This comment was reaffirmed. There seems to be 1282 consensus that this isn't something that needs to be in the BGP spec. 1284 2.19. Appendix Section 6.2: Processing Messages on a Stream Protocol 1286 Status: Consensus 1287 Change: Yes 1288 Summary: Remove the section entirely, as this is something that does 1289 not belong in the base spec. 1291 Discussion: 1293 This first came up in response to Issue 17: 1295 There was one comment suggesting that section 6.2 (Processing 1296 Messages on a Stream Protocol" mentioned this. 1298 The original reviewer responded that the out-of-scope comment was 1299 out-of-place and referred the responder to section 6.2 (appendix 6) 1301 The original reviewer stated that he is happy with just adding a 1302 reference to section 6.2 in appendix 6 and leaving it at that. 1304 Curtis suggested we just add a reference to Stevens in appendix 6. 1305 6.2 and be done with it. Specifically: 1307 6.2 Processing Messages on a Stream Protocol 1309 BGP uses TCP as a transport mechanism. If you are unsure as to how 1310 to handle asynchronous reads and writes on TCP sockets please refer 1311 to Unix Network Programming [RWStevens] or other introductory text 1312 for programming techniques for the operating system and TCP 1313 implementation that you are using. 1315 There were further suggestions to remove the section entirely as out- 1316 of-scope. At least 3 people agreed with this. 1318 Alex responded that he sees no reason to remove it, but wouldn't have 1319 a problem if the WG decides to do so. 1321 There seems to be general agreement that this section should be 1322 removed. 1324 N.B. This also affects issue 12. 1326 2.20. Wording fix in Section 4.3 1328 Status: Consensus 1329 Change: Yes 1330 Summary: A small change for clarity in section 4.3 1332 Discussion: 1334 This suggestion grew out of the discussion on Issue 18. 1336 The following change was suggested in section 4.3, second line of the 1337 first paragraph: 1339 s/UPDATE packet/UPDATE message/ 1341 Yakov agreed to this change and updated the draft. 1343 2.21. Authentication Text Update 1345 Status: Consensus 1346 Change: No 1347 Summary: The consensus is that additional references to RFC2385 are 1348 not necessary. 1350 Discussion: 1352 P. 10, "Authentication Data:" section you might want to add this, It 1353 is also possible to use MD5 (RFC2385) at the transport layer to 1354 validate the entire BGP message. 1356 Yakov replied to this: 1358 There is already text that covers this: 1360 "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may 1361 be used in addition to BGP's own authentication mechanisms." 1363 .... 1365 "In addition, BGP supports the ability to authenticate its data 1366 stream by using [RFC2385]." 1368 So, I see no need to add the text proposed above. 1370 Ishi agreed with Yakov. Jonathan disagreed since he thought no one 1371 uses BGP auth. Ishi replied that there are lots of people who do use 1372 it. Jonathan replied with a clarification question: "Who uses *BGP's 1373 own* authentication mechanisms???" Ron Bonica replied that they use 1374 BGP auth. There was some additional discussion over who implements 1375 simple password authentication vs. MD5. 1377 After further discussion, the consensus seems to be that we should 1378 leave the text as it is for the reasons Yakov pointed out. There was 1379 some discussion over opening a new issue to discuss deprecating the 1380 BGP auth mechanism discussed in RFC1771 in favor of the mechanism in 1381 RFC2385. 1383 The issue of Deprecating BGP AUTH is discussed in issue 62. 1385 2.22. Scope of Path Attribute Field 1387 Status: Consensus 1388 Change: Yes 1389 Summary: This is already being covered by text that has been added to 1390 the -18 draft. 1392 Discussion: 1394 P. 12, right after "Path Attributes". The following sentence should 1395 be added to this section to clarify the scope of the Path Attribute 1396 field. "All attributes in the Path Attribute field represent the 1397 characteristics of all the route prefixes defined in the NLRI field 1398 of the message". 1400 Yakov replied to this that: 1402 This will be covered by the following text in 3.1 that will be in the 1403 -18 version (see also issue 54). 1405 Routes are advertised between BGP speakers in UPDATE messages. 1406 Multiple routes that have the same path attributes can be advertised 1407 in a single UPDATE message by including multiple prefixes in the NLRI 1408 field of the UPDATE message. 1410 Therefore there is no need to add the sentence proposed above. 1412 There were no objections to this statement, so this issue has been 1413 moved into consensus. 1415 2.23. Withdrawn and Updated routes in the same UPDATE message 1417 Status: Consensus 1418 Change: No 1419 Summary: For various reasons, not least of which is compatibility 1420 with existing implementations, the decision was made to keep thing 1421 the way they are. 1423 Discussion: 1425 4. P.16, last paragraph in section 4.3 as stated, "An UPDATE message 1426 should not include the same address prefix in the WITHDRAWN ROUTES 1427 and Network Layer Reachability Information fields, however a BGP 1428 speaker MUST be able to process UPDATE messages in this form. A BGP 1429 speaker should treat an UPDATE message of this form as if the 1430 WITHDRAWN ROUTES doesn't contain the address prefix." 1432 This complexity could have been avoided if withdrawn routes and NLRI 1433 prefixes with their attributes were mutually exclusive of each other 1434 and appeared in different update messages. If that was the case, the 1435 priority of which field to process first would have been as simple as 1436 using "first come, first served" message processing approach. 1438 Yakov commented that this would make the case where they are both in 1439 the same message unspecified. 1441 John commented that this is something we don't want to change this 1442 late in the game. Although it was acknowledged that this might be a 1443 good change if we were working from a clean slate. 1445 Ben acceded that this was somewhat wishful thinking on his part. 1447 Curtis's comment seems to coincide with this message, stating: 1449 The existing rules are very clear. 1451 Summarized: 1453 If an UPDATE contains only a withdraw for a prefix, then withdraw 1454 whatever route the peer had previously sent. 1456 If an UPDATE contains the prefix only in the NLRI section, replace 1457 whatever route had previously been advertised by the peer or add a 1458 route if there was no previous route, in both cases adding a route 1459 with the current attributes. 1461 Don't put the same prefix in the same in both the withdraw and NLRI 1462 section of the same update. 1464 If you receive an UPDATE with the same prefix in both the withdraw 1465 and NLRI, ignore the withdraw. [Some older implementations thought 1466 this was a good way to say "delete then add".] 1468 Process UPDATEs from the same peer in the order received. 1470 And goes on to say, that to him, these rules are clear from the 1471 existing text. 1473 Consensus is that while this would be nice, we need to stick with 1474 what we have, and move on. 1476 2.24. Addition or Deletion of Path Attributes 1478 Status: Consensus 1479 Change: Yes 1480 Summary: Add the following to section 3.1: 1482 Changing the attributes of a route is accomplished by advertising a 1483 replacement route. The replacement route carries new (changed) 1484 attributes and has the same NLRI as the original route. 1486 Discussion: 1488 5. P. 20 Its not stated how we delete or modify Path Attributes 1489 associated with NLRI prefixes. 1491 A response to this comment said that this is implicit in the 1492 definition of "route" and the general withdraw/replace behavior and 1493 therefore doesn't need to be repeated. 1495 Ben responded saying that, while there was an assumption, there was 1496 no well defined mechanism, and this leads to ambiguity. 1498 John responded, no need to define everything explicitly, or we'll be 1499 here forever. 1501 Picking this thread up again, Yakov argued: 1503 By *definition* a route is a pair. From that 1504 definition it follows that changing one or more path attributes of a 1505 route means changing a route, which means withdrawing the old route 1506 (route with the old attributes) from service and advertising a new 1507 route (route with the new attributes). Procedures for doing this are 1508 well-defined (see section 3.1), and therefore no new text to cover 1509 this is needed. 1511 Jonathan agreed with this statement, but Ben argued that the text in 1512 section 3 is insufficient the way it is currently written. After two 1513 iterations, Ben and Yakov agreed on this formulation for an update to 1514 section 3.1: 1516 Changing the attributes of a route is accomplished by advertising a 1517 replacement route. The replacement route carries new (changed) 1518 attributes and has the same NLRI as the original route. 1520 Jeff objected somewhat to the wording, since, because of a bgp route 1521 is defined as a pair, changing either part of 1522 that pair, by definition, changes the route. He acknowledged that 1523 this might fall under the category of implementation detail. 1525 Yakov presented the view that he thought we were at consensus with 1526 the text he proposed above. Jonathan agreed. There were no 1527 objections, so this is moved to Consensus. 1529 2.25. NEXT_HOP Semantics 1531 Status: Consensus 1532 Change: No 1533 Summary: After responders pointed out another sentence, this comment 1534 was resolved. Things will stay the way they are. 1536 Discussion: 1538 1. P.28, 2nd to last paragraph. The line that reads, "To be 1539 semantically correct, the IP address in the NEXT_HOP must not be the 1540 IP address of the receiving speaker, and the NEXT_HOP IP address must 1541 either be the sender's IP address (used to establish the BGP 1542 session), or the interface associated with the NEXT_HOP IP address 1543 must share a common subnet with the receiving BGP speaker..." 1545 This is not always true, what if the current ASBR BGP router is 1546 advertising an external AS route (to a IBGP Peer) whose NEXT_HOP IP 1547 address is the IP address of the EBGP peer in the other AS? 1549 A response to this pointed out that right before this is a sentence 1550 stating that this only applied to eBGP links, and only when the peers 1551 are one hop from each other, so a modification is unnecessary. This 1552 response was confirmed with another. 1554 The original reviewer acknowledged this and withdrew the comment. 1556 The consensus is to leave things the way they are. 1558 2.26. Attributes with Multiple Prefixes 1560 Status: Consensus 1561 Change: No 1562 Summary: After some discussion, the consensus is to keep things the 1563 same since the suggested behavior is defined in the message format. 1565 Discussion: 1567 2. P. 29, Section 6.3. Add this rule near the attribute rules. 1568 "Multiple prefixes that require the same attribute type with 1569 different values must never appear in the same update message". 1571 A response to this suggested that this text is unnecessary since this 1572 behavior is ruled out by the way the message format is defined. 1574 The original commenter agrees with the responder. The consensus is 1575 to leave things the way they are. 1577 2.27. Allow All Non-Destructive Messages to Refresh Hold Timer 1579 Status: Consensus 1580 Change: No 1581 Summary: It is agreed that this is a change that exceeds the original 1582 goal of this draft revision. This goal is to document existing 1583 practice in an interoperable way. 1585 Discussion: 1587 3. P. 29, Section 6.5, Please rewrite this sentence from: "If a 1588 system does not receive successive KEEPALIVE and/or UPDATE and/or 1589 NOTIFICATION messages within the period specified in the Hold Time 1590 field of the OPEN message ..." 1592 To This: "If a system does not receive successive KEEPALIVE and/or 1593 UPDATE and/or any other BGP message within the period specified in 1594 the Hold Time field of the OPEN message ..." 1596 There is disagreement on this change. It has been discussed in other 1597 threads. 1599 The original commenter acknowledged that this is something that would 1600 be "adding a new feature" as opposed to the stated goal of 1601 "documenting what exists." He suggested that the ADs decide if we 1602 should open the door for new features or not. 1604 Yakov replied to this that he would suggest we keep things as is, 1605 since the purpose is to document current implementations. 1607 This did not meet with any objections, so this issue has been moved 1608 into consensus. 1610 2.28. BGP Identifier as Variable Quantity 1612 Status: Consensus 1613 Change: No 1614 Summary: The consensus is that changing the BGP Identifier in the 1615 base draft is out-of-scope at this point in the draft evolution. 1617 Discussion: 1619 4. P. 31, section 6.8, Please rewrite this sentence from: "Comparing 1620 BGP Identifiers is done by treating them as (4-octet long) unsigned 1621 integers." 1623 To This: "Comparing BGP Identifiers is done by treating them as large 1624 numbers based on their IP Address type (e.g. IPv4, IPv6, etc.)." 1626 A response to this was that since BGP Identifier is defined in the 1627 base spec as a 4 byte unsigned integer, and not a variable quantity, 1628 the sentence as written is acceptable. This was also confirmed by 1629 another response. 1631 The original commenter was thinking of IPv6, and providing sufficient 1632 space to allow a full v6 address to be used. 1634 Again, responders said that this is out-of-scope for the current 1635 draft. 1637 2.29. State Why Unresolveable Routes Should Be Kept in Adj-RIB-In 1639 Status: Consensus 1640 Change: Yes 1641 Summary: Add: 1643 "in case they become resolvable" after the last sentence on p. 46. 1645 Discussion: 1647 5. P.46, last sentence, "However, corresponding unresolvable routes 1648 SHOULD be kept in the Adj-RIBs-In." It would helpful if the author 1649 states why unresolvable routes should be kept in Adj-RIBs-In? 1651 A response to this stated "In case they become resolvable" 1653 Yakov responded that: 1655 I suggest we add "in case they become resolvable" after the last 1656 sentence on p. 46. 1658 The original commenter stated that: Then the point that the peer will 1659 not refresh the route if we drop them (unless we use Route Refresh) 1660 because they are unreachable should be made. 1662 Yakov also responded that: 1664 This should be clear from the following text in Section 3: 1666 The initial data flow is the portion of the BGP routing table that is 1667 allowed by the export policy, called the Adj-Ribs-Out (see 3.2). 1668 Incremental updates are sent as the routing tables change. BGP does 1669 not require periodic refresh of the routing table. 1671 Jonathan, who was the original commenter, agreed with both the 1672 changed text and the clarity of section 3. 1674 2.30. Mention Other Message Types 1676 Status: Consensus 1677 Change: Yes 1678 Summary: Add a reference to RFC2918 at the end of the type code list. 1680 Discussion: 1682 1. P. 7 Type: Need to add the new message types such as, Capability 1683 Negotiations (RFC2842), Route Refresh, etc. 1685 One response argued that these are out-of-scope of the base document. 1686 One response agreed, but thought that it should be capability and not 1687 message type. The original commenter responded about Message type 1688 from the capability draft. 1690 Sue mentioned this would be added in the second round. 1692 Yakov replied that: 1694 The only new message type that is covered by an RFC (rather than just 1695 an Internet Draft) is the Refresh message. With this in mind how 1696 about replacing the following: 1698 The following type codes are defined: 1700 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE 1702 with 1703 This document defines the following type codes: 1705 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE 1707 [RFC2918] defines one more type code. 1709 Jonathan agreed with this change. This issue has been moved to 1710 consensus. 1712 2.31. Add References to Additional Options 1714 Status: Consensus 1715 Change: Yes 1716 Summary: Consensus to add: 1718 [RFC2842] defines another Optional Parameter. 1720 Discussion: 1722 2. P. 9, right after "This document defines the following optional 1723 parameters:" Need to mention possible options, such as: Capabilities 1724 (RFC2842), Multiprotocol extensions (RFC2858), Route Refresh 1725 (RFC2918). 1727 One response agreed that adding references would be fine. A second 1728 response agreed. 1730 Yakov replied that: 1732 Please note that only rfc2842 defines an OPEN optional parameter. 1733 Neither rfc2858 nor rfc2918 defines an OPEN optional parameter. 1735 With this in mind I would suggest to add the following text: 1737 [RFC2842] defines another Optional Parameter. 1739 The original poster agreed with this modification. This issue is at 1740 consensus. 1742 2.32. Clarify EGP Reference 1744 Status: Consensus 1745 Change: No 1746 Summary: The consensus is that this was addressed in 32.1, so we can 1747 close this. 1749 Discussion: 1751 3. P. 13, EGP, are there other EGP protocols other than BGP that are 1752 in use? If not, change EGP to BGP. 1754 A response to this suggested that we add a reference to [1] (the EGP 1755 spec) here. 1757 Another response clarified that this refers to EGP-the-protocol and 1758 NOT the class. 1760 Another response disagreed, but suggested that: 1762 IGP = network was explicitly introduced into bgp (network cmd) 1763 INCOMPLETE = network was implicitly introduced into bgp 1764 (redistribute) EGP = other 1766 The original commenter thought that this referred to EGP-the-class of 1767 protocols. And why not use BGP therefore, as the only EGP. 1769 There was some discussion over whether or not we should mention 1770 something that is historical. 1772 Jeff suggested a footnote in the Origin section about EGP. 1774 Curtis suggested that we state that the EGP in ORIGIN is deprecated, 1775 but retain the value to document what it used to mean. 1777 This reviewer thinks a statement about whether this "EGP" origin 1778 refers to the protocol or the class or protocols would be useful. 1780 Yakov replied that an EGP reference will be added (see issue 9). 1782 Yakov also stated that he doesn't see what is wrong with the current 1783 text, and suggested we keep it. This includes leaving out any 1784 reference to the status of the EGP spec. He sees that it is clear 1785 from context that we are talking about "the EGP" [RFC904]. 1787 Jeff noted that this issue has been sufficiently addressed in the 1788 solution to 32.1. This met with agreement. We are at consensus. 1790 2.32.1. EGP ORIGIN Clarification 1792 Status: Consensus 1793 Change: Yes 1794 Summary: Change section 5.1.1 to read: 1796 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1797 shall be generated by the speaker that originates the associated 1798 routing information. Its value SHOULD NOT be changed by any other 1799 speaker." 1801 Consensus to change: 1803 1 EGP - Network Layer Reachability Information learned via the EGP 1804 protocol 1806 to: 1808 1 EGP - Network Layer Reachability Information learned via the EGP 1809 protocol [RFC904] 1811 Discussion: 1813 This discussion is picked up again in the "Review of 1814 draft-ietf-idr-bgp4-17" thread, where specific text is proposed: 1816 Old: 1818 "ORIGIN is a well-known mandatory attribute that defines the origin 1819 of the path information. The data octet can assume the following 1820 values: 1822 Value Meaning 1824 0 IGP - Network Layer Reachability Information is interior to the 1825 originating AS 1827 1 EGP - Network Layer Reachability Information learned via the EGP 1828 protocol 1830 2 INCOMPLETE - Network Layer Reachability Information learned by some 1831 other means" New: 1833 "ORIGIN is a well-known mandatory attribute that defines the origin 1834 of the path information. The data octet can assume the following 1835 values: 1837 Value Meaning 1839 0 IGP - NLRI was explicitly introduced into bgp 1841 1 EGP - this value was administratively configured to affect policy 1842 decisions or NLRI was learned via the EGP protocol [1] 1844 2 INCOMPLETE - NLRI was implicitly introduced into bgp" 1846 since: 1) The network command sets the origin to IGP and I remember 1847 seeing somewhere that only static routes should be set to IGP. 2) The 1848 primary use of EGP value is policy 3) EGP seems to still exist, 1849 anyway even if it does not it is not worth re-writing the world. 1851 Also, change: "5.1.1 ORIGIN 1853 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1854 shall be generated by the autonomous system that originates the 1855 associated routing information. It shall be included in the UPDATE 1856 messages of all BGP speakers that choose to propagate this 1857 information to other BGP speakers." 1859 to: "5.1.1 ORIGIN 1861 The value of the ORIGIN attribute shall be set by the speaker that 1862 originates the associated NLRI. Its value shall not be changed by 1863 any other speaker unless the other speaker is administratively 1864 configured to do so to affect policy decisions." 1866 since: 1) It is already defined as well-known mandatory attribute. 2) 1867 It may be set differently within the same AS (not saying this is 1868 good). 3) It is commonly used for policy, but by default does not get 1869 changed. 4) Speakers have no choice, it is mandatory. 1871 After much continued discussion on this in the "issue 32.1" thread, 1872 we seem to have come to a consensus that section 5.1.1 should read: 1874 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1875 shall be generated by the speaker that originates the associated 1876 routing information. Its value should not be changed by any other 1877 speaker unless the other speaker is administratively configured to do 1878 so to affect policy decisions." 1880 This text met with a number of agreements, and one disagreement 1881 stating that we shouldn't have the "unless administratively 1882 configured" portion. 1884 After some further discussion, we have this text on the table: 1886 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1887 generated by the BGP speaker that originates the associated BGP 1888 routing information. The attribute shall be included in the UPDATE 1889 messages of all BGP speakers that choose to propagate this 1890 information to other BGP speakers. 1892 Jonathan suggested that we change "propagate this information" to 1893 "forward this route". He also mentioned that he would prefer 1894 something more explicit instead of/in addition to "The attribute 1895 shall be included in the UPDATE messages of all BGP speakers that 1896 choose to propagate this information to other BGP speakers." such as 1897 "other speakers do not change the ORIGIN value." 1899 On the issue of making the EGP ORIGIN type more clear Andrew 1900 proposed: 1902 To me, there seems to be sufficient confusion around the "EGP" 1903 reference to merit some sort of clarification. The simplest 1904 modification would be to change: 1906 1 EGP - Network Layer Reachability Information learned via the EGP 1907 protocol 1909 to: 1911 1 EGP - Network Layer Reachability Information learned via the EGP 1912 protocol [RFC904] 1914 That would clarify that we're talking about the protocol, and not the 1915 class-of-protocols, or EBGP. It would leave unstated that this could 1916 theoretically be used to muck with route selection. I think that is 1917 ok. If operators want to override ORIGIN to affect some hoho magic, 1918 they are welcome to do so, but I don't think it needs to be 1919 documented in the base spec. 1921 This met with a number of agreements. 1923 On the second text section we are working on, Jonathan objected to 1924 the current working text below and suggested an alternate: 1926 CHANGE: 1928 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1929 generated by the BGP speaker that originates the associated BGP 1930 routing information. The attribute shall be included in the UPDATE 1931 messages of all BGP speakers that choose to propagate this 1932 information to other BGP speakers." 1934 TO: 1936 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1937 shall be generated by the speaker that originates the associated 1938 routing information. Its value should not be changed by any other 1939 speaker unless the other speaker is administratively configured to do 1940 so to affect policy decisions." 1942 -or- 1943 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1944 shall be generated by the speaker that originates the associated 1945 routing information. Its value should not be changed by any other 1946 speaker." 1948 Jonathan cited a recent example of someone who was still confused by 1949 this section of the text in -17 (not specifically the working text). 1951 Yakov proposed this as final text: 1953 In 4.3: 1955 a) ORIGIN (Type Code 1): 1957 ORIGIN is a well-known mandatory attribute that defines the origin of 1958 the path information. The data octet can assume the following 1959 values: 1961 Value Meaning 1963 0 IGP - Network Layer Reachability Information is interior to the 1964 originating AS 1966 1 EGP - Network Layer Reachability Information learned via the EGP 1967 protocol [RFC904] 1969 2 INCOMPLETE - Network Layer Reachability Information learned by some 1970 other means 1972 Usage of this attribute is defined in 5.1.1. 1974 In 5.1.1: 1976 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1977 shall be generated by the speaker that originates the associated 1978 routing information. Its value SHOULD NOT be changed by any other 1979 speaker." 1981 This met with agreement. This issue is at consensus. 1983 2.32.2. BGP Destination-based Forwarding Paradigm 1985 Status: Consensus 1986 Change: Yes 1987 Summary: After much discussion, this is the consensus: This text in 1988 the current draft: 1990 To characterize the set of policy decisions that can be enforced 1991 using BGP, one must focus on the rule that a BGP speaker advertises 1992 to its peers (other BGP speakers which it communicates with) in 1993 neighboring ASs only those routes that it itself uses. This rule 1994 reflects the "hop-by-hop" routing paradigm generally used throughout 1995 the current Internet. Note that some policies cannot be supported by 1996 the "hop-by-hop" routing paradigm and thus require techniques such as 1997 source routing (aka explicit routing) to enforce. For example, BGP 1998 does not enable one AS to send traffic to a neighboring AS intending 1999 that the traffic take a different route from that taken by traffic 2000 originating in the neighboring AS. On the other hand, BGP can 2001 support any policy conforming to the "hop-by-hop" routing paradigm. 2002 Since the current Internet uses only the "hop-by-hop" inter-AS 2003 routing paradigm and since BGP can support any policy that conforms 2004 to that paradigm, BGP is highly applicable as an inter-AS routing 2005 protocol for the current Internet. 2007 will be replaced in -18 with the following text: 2009 Routing information exchanged via BGP supports only the destination- 2010 based forwarding paradigm, which assumes that a router forwards a 2011 packet based solely on the destination address carried in the IP 2012 header of the packet. This, in turn, reflects the set of policy 2013 decisions that can (and can not) be enforced using BGP. Note that 2014 some policies cannot be supported by the destination-based forwarding 2015 paradigm, and thus require techniques such as source routing (aka 2016 explicit routing) to be enforced*. Such policies can not be enforced 2017 using BGP either. For example, BGP does not enable one AS to send 2018 traffic to a neighboring AS for forwarding to some destination 2019 (reachable through but) beyond that neighboring AS intending that the 2020 traffic take a different route to that taken by the traffic 2021 originating in the neighboring AS (for that same destination). On 2022 the other hand, BGP can support any policy conforming to the 2023 destination-based forwarding paradigm. 2025 Discussion: 2027 In response to these proposals, Yakov proposed that the real problem 2028 is that it is not clear that BGP is build to support the destination- 2029 based forwarding paradigm. To fix this, it was proposed that: 2031 2033 To characterize the set of policy decisions that can be enforced 2034 using BGP, one must focus on the rule that a BGP speaker advertises 2035 to its peers (other BGP speakers which it communicates with) in 2036 neighboring ASs only those routes that it itself uses. This rule 2037 reflects the "hop-by-hop" routing paradigm generally used throughout 2038 the current Internet. Note that some policies cannot be supported by 2039 the "hop-by-hop" routing paradigm and thus require techniques such as 2040 source routing (aka explicit routing) to enforce. For example, BGP 2041 does not enable one AS to send traffic to a neighboring AS intending 2042 that the traffic take a different route from that taken by traffic 2043 originating in the neighboring AS. On the other hand, BGP can 2044 support any policy conforming to the "hop-by-hop" routing paradigm. 2045 Since the current Internet uses only the "hop-by-hop" inter-AS 2046 routing paradigm and since BGP can support any policy that conforms 2047 to that paradigm, BGP is highly applicable as an inter-AS routing 2048 protocol for the current Internet. 2050 2052 Routing information exchanged via BGP supports only the destination- 2053 based forwarding paradigm, which assumes that a router forwards a 2054 packet based solely on the destination address carried in the IP 2055 header of the packet. This, in turn reflects the set of policy 2056 decisions that can (and can not) be enforced using BGP. Note that 2057 some policies cannot be supported by the destination-based forwarding 2058 paradigm and thus require techniques such as source routing (aka 2059 explicit routing) to enforce. Such policies can not be enforced 2060 using BGP either. For example, BGP does not enable one AS to send 2061 traffic to a neighboring AS intending that the traffic take a 2062 different route from that taken by traffic originating in the 2063 neighboring AS. On the other hand, BGP can support any policy 2064 conforming to the destination-based forwarding paradigm. 2066 Curtis thinks the newer text here is more clear. 2068 In response to the new text, Christian Martin proposed a slightly 2069 different new text: 2071 Routing information exchanged via BGP supports only the destination- 2072 based forwarding paradigm, which assumes that a router forwards a 2073 packet based solely on the destination address carried in the IP 2074 header of the packet. This, in turn reflects the set of policy 2075 decisions that can (and can not) be enforces using BGP. Note that 2076 some policies cannot be supported by the destination-based forwarding 2077 paradigm and thus require techniques such as source routing (aka 2078 explicit routing) to enforce. Such policies can not be enforced 2079 using BGP either. For example, BGP does not enable one AS to send 2080 traffic to a neighboring AS based on prefixes originating from the 2081 local AS. On the other hand, BGP can support any policy conforming 2082 to the destination-based forwarding paradigm. 2084 To which Yakov replied: 2086 Routing information exchanged via BGP supports only the destination- 2087 based forwarding paradigm, which assumes that a router forwards a 2088 packet based solely on the destination address carried in the IP 2089 header of the packet. This, in turn, reflects the set of policy 2090 decisions that can (and can not) be enforces using BGP. Note that 2091 some policies cannot be supported by the destination-based forwarding 2092 paradigm, and thus require techniques such as source routing (aka 2093 explicit routing) to enforce. Such policies can not be enforced 2094 using BGP either. For example, BGP does not enable one AS to send 2095 traffic through a neighboring AS to some destination (which is 2096 outside of the neighboring AS, but is reachable through the 2097 neighboring AS) intending that the traffic take a different route 2098 from that taken by the traffic to the same destination that 2099 originating in the neighboring AS. On the other hand, BGP can 2100 support any policy conforming to the destination-based forwarding 2101 paradigm. 2103 And Chris responded: 2105 Routing information exchanged via BGP supports only the destination- 2106 based forwarding paradigm, which assumes that a router forwards a 2107 packet based solely on the destination address carried in the IP 2108 header of the packet. This, in turn, reflects the set of policy 2109 decisions that can (and can not) be enforces using BGP. Note that 2110 some policies cannot be supported by the destination-based forwarding 2111 paradigm, and thus require techniques such as source routing (aka 2112 explicit routing) to enforce. Such policies can not be enforced 2113 using BGP either. For example, BGP does not enable one AS to send 2114 traffic through a neighboring AS to some destination beyond the 2115 neighboring AS intending that the traffic take a different route from 2116 that taken by traffic to the same destination which originates in the 2117 neighboring AS. In other words, the BGP policy of a local AS cannot 2118 affect the downstream (aka, away from the local AS) forwarding policy 2119 of a remote AS. On the other hand, BGP can support any policy 2120 conforming to the destination-based forwarding paradigm. 2122 Tom Petch preferred Yakov's second formulation, with these changes: 2124 policies can not be enforced using BGP either. For example, BGP does 2125 not enable one AS to send traffic ! to a neighboring AS for 2126 forwarding to some destination (reachable through but) beyond ! that 2127 neighboring AS intending that ! the traffic take a different route to 2128 that taken by the traffic ! originating in the neighboring AS (for 2129 that same destination). 2131 On the other hand, BGP can support any policy conforming to the 2132 destination-based forwarding paradigm. 2134 Yakov agreed to Tom's suggested changes. 2136 2.33. Add "Optional Non-Transitive" to the MED Section 2138 Status: Consensus 2139 Change: Yes 2140 Summary: Add "Optional Non-Transitive" to MED Section Add "well-known 2141 mandatory" to the NEXT_HOP Section 2143 Discussion: 2145 4. P.23, change the following: 2147 "The MULTI_EXIT_DISC attribute may be used on external (inter-AS) 2148 links to discriminate among multiple exit or entry points to the same 2149 neighboring AS ..." 2151 To the following: 2153 "The MULTI_EXIT_DISC is an optional non-transitive attribute which 2154 may be used on external (inter-AS) links to discriminate among 2155 multiple exit or entry points to the same neighboring AS ..." 2157 A responder disagreed, and stated reasons "covered elsewhere" 2158 Original commenter asked for reasons, since the modification seemed 2159 obvious to him. 2161 Yakov agreed to make this change in -18. 2163 Jonathan replied that: 2165 5.1.3 NEXT_HOP also, it is missing " well-known mandatory". 2167 Yakov also agreed to make this change. 2169 2.34. Timer & Counter Definition 2171 Status: Consensus 2172 Change: No 2173 Summary: No discussion, no text proposed, defaults to consensus for 2174 no change. 2176 Discussion: 2178 5. In section 8, there are a number of Timers, Counters, etc. that 2179 need to be explicitly defined before they are used by the FSM. 2180 Perhaps these definitions should go in the Glossary section. 2182 There has been no further discussion on this issue. Unless it is 2183 brought up again, this issue is in consensus, with no change. 2185 2.35. Fix Typo 2187 Status: Consensus 2188 Change: Yes 2189 Summary: Fix a Typo. No discussion, but this seem clear. 2191 Discussion: 2193 1. P. 41. Typing error, "Each time time the local system...". 2195 2.36. Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 2197 Status: Consensus 2198 Change: Yes 2199 Summary: This change requires a glossary. Yakov has committed to 2200 having a section where commonly used terms are defined in draft 18, 2201 so this issue is at consensus. 2203 Discussion: 2205 2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in 2206 the glossary, so when they are used in section 9.1, it is well 2207 understood what they are. 2209 Yakov replied: 2211 will be added to the section "Definition of commonly used terms" in 2212 -18 version. 2214 2.37. Combine "Unfeasible Routes" and "Withdrawn Routes" 2216 Status: Consensus 2217 Change: Yes 2218 Summary: Add the following terms to the "commonly used terms 2219 section": 2221 Feasible route A route that is available for use. 2223 Unfeasible route A previously advertised feasible route that is no 2224 longer available for use. 2226 Discussion: 2228 3. P. 45, Phase I, There is no definition of what are unfeasible 2229 routes? Are they the same as withdrawn routes? If so, the two 2230 should be combined to one name. 2232 Ishi replied to this that he thought that we could combine the two 2233 terms, since there is limited difference from an implementation 2234 standpoint. 2236 Yakov replied: 2238 The routes are withdrawn from service because they are unfeasible, 2239 not because they are "withdrawn". So, we need to keep the term 2240 "unfeasible" to indicate the *reason* why a route could be withdrawn. 2241 On the other hand, "withdrawn" is used as a verb, and to the best of 2242 my knowledge "unfeasible" can't be used as a verb. With this in 2243 mind, I don't think that we can combine the two into a single term. 2245 Ishi replied that he was convinced, and that the terms should stay 2246 separate. 2248 Andrew asked the list if we should define these terms in the 2249 "commonly used terms" section in draft -18. 2251 Ben replied that if we use them a lot, we should define them, and if 2252 not local definitions will suffice. 2254 There was some back and forth about the necessity of defining terms 2255 which should be obvious. 2257 mrr actually checked the doc to see if we were consistently using the 2258 terms, and found: 2260 It turns out there there is an inconsistency in the usage of the word 2261 withdrawn. 2263 Section 3.1: 2265 There are three methods by which a given BGP speaker can indicate 2266 that a route has been withdrawn from service: 2268 ... 2270 b) a replacement route with the same NLRI can be advertised, or 2272 ... 2274 Later, in the definition of Withdrawn Routes Length, we have: 2276 A value of 0 indicates that no routes are being withdrawn from 2277 service, 2279 Taken together, this could be construed as meaning that a Withdrawn 2280 Routes Length of 0 indicates that all routes included in the UPDATE 2281 represent newly feasible routes... not replacement routes. 2283 Now, it's possible that this problem has been removed by changes to 2284 the text that have not yet been incorporated in to a new draft; 2285 however, it arose because the text, for the most part, does _not_ use 2286 "withdrawn" in the standard way. Instead, it refers to routes 2287 included in the WITHDRAWN ROUTES field of an UPDATE message. 2288 Consequently, I propose defining a "withdrawn route" as follows: 2290 Withdrawn route: a route included in the WITHDRAW ROUTES field of an 2291 UPDATE message. 2293 Regardless of whether or not this definition is included, Section 3.1 2294 should be changed from: 2296 There are three methods by which a given BGP speaker can indicate 2297 that a route has been withdrawn from service: 2299 to: 2301 There are three methods by which a given BGP speaker can indicate 2302 that a route has been removed from service: 2304 or: 2306 There are three methods by which a given BGP speaker can indicate 2307 that a route is now unfeasible: 2309 After some further off-list discussion, mrr agreed that this 2310 inconsistency is extremely minor, and withdrew his comment. feasible 2311 and unfeasible route will be defined in the "commonly used terms" 2312 section to clear up any confusion. 2314 2.38. Clarify Outbound Route Text 2316 Status: Consensus 2317 Change: No 2318 Summary: Consensus that the issue was sufficiently minor to leave 2319 things alone. 2321 Discussion: 2323 4. P. 50, line, "If a route in Loc-RIB is excluded from a particular 2324 Adj-RIB-Out the previously advertised route in that Adj-RIB-Out must 2325 be withdrawn from service by means of an UPDATE message (see 9.2)." 2327 Would like to rephrase the sentence for clarity, "If a route in Loc- 2328 RIB is excluded from a particular Adj-RIB-Out and was previously 2329 advertised via Adj-RIB-Out, it must be withdrawn from service by 2330 means of an UPDATE message (see 9.2)." 2332 One comment suggested either leave it alone, or remove "via Adj-RIB- 2333 Out". 2335 The original commenter withdrew the comment. 2337 2.39. Redundant Sentence Fragments 2339 Status: Consensus 2340 Change: Yes 2341 Summary: Fix typo & parentheses. 2343 Discussion: 2345 5. P. 50, section 9.1.4, The two fragments of this sentence are 2346 redundant and don't say anything new or simplify the content. Just 2347 keep one fragment. 2349 "A route describing a smaller set of destinations (a longer prefix) 2350 is said to be more specific than a route describing a larger set of 2351 destinations (a shorted prefix); similarly, a route describing a 2352 larger set of destinations (a shorter prefix) is said to be less 2353 specific than a route describing a smaller set of destinations (a 2354 longer prefix)." 2356 There was a comment that disagreed, thinking that both "more 2357 specific" and "less specific" need to be defined. And suggested that 2358 only the third and forth parentheses need to be dropped. 2360 The original commenter agreed with the parentheses changes. 2362 Yakov agreed to drop the third and fourth parentheses in the -18 2363 version. 2365 Jonathan replied to this: 2367 Disagree, the text if fine the way it is, except you need to change 2368 "shorted" to "shorter". 2370 After minimal further discussion, it was decided we are at a 2371 consensus on this issue to fix the typo and drop the third and fourth 2372 parentheses. 2374 2.40. Section 9.2.1.1 - Per Peer vs. Per Router 2375 MinRouteAdvertisementInterval 2377 Status: Consensus 2378 Change: No 2379 Summary: The consensus is that current practice allows for the 2380 MinRouteAdvertisementInterval to be set per peer, so the text should 2381 be kept the same. 2383 Discussion: 2385 6. P. 52, section 9.2.1.1 Change this sentence for clarity, "This 2386 rate limiting procedure applies on a per-destination basis, although 2387 the value of MinRouteAdvertisementInterval is set on a per BGP peer 2388 basis." 2390 To This: "This rate limiting procedure applies on a per-destination 2391 basis, although the value of MinRouteAdvertisementInterval is set on 2392 a BGP router (same value for all peers) basis." 2394 There was a comment disagreeing with this proposal. It was later 2395 elaborated on to include that the reason for disagreement was that 2396 the proposed changes changed the protocol and not just a practice 2397 clarification. Ben responded asking for how this is a protocol 2398 change, he saw it as a clarification. Perhaps there is something 2399 deeper that needs to be clarified? Again, response to this is that 2400 current implementations allow the MinRouteAdvertisementInterval to be 2401 set per-peer, not per-router. 2403 Original reviewer conceded the point. 2405 There was some additional discussion on this point. Most of it was 2406 along the lines of extracting what was really implemented and 2407 supported among various vendors. The conclusion was the same. 2409 2.41. Mention FSM Internal Timers 2411 Status: Consensus 2412 Change: No 2413 Summary: No discussion on this issue. No text proposed. Perhaps 2414 this is in the FSM section of the draft? Either way, it defaults to 2415 consensus with no change. 2417 Discussion: 2419 7. P. 61, item 6.4. Although all the BGP protocol interfacing 2420 timers are mentioned, there are a few FSM internal timers mentioned 2421 in the spec that need to be covered here as well. 2423 There has been no discussion on this, it now defaults to consensus 2424 with no change. 2426 2.42. Delete the FSM Section 2428 Status: Consensus 2429 Change: No 2430 Summary: There was some confusion on the question: Is the FSM draft 2431 going to be a separate document, or incorporated into the base draft. 2432 The consensus is that it is going to become part of the base draft, 2433 so the FSM section will be kept, and elaborated on. 2435 Discussion: 2437 8. Since there is going to be an FSM spec, do we need to have FSM 2438 descriptions in this spec. Maybe the FSM section should be delete. 2440 There was one response agreeing with this. One response asking for 2441 clarification: Was this a move to remove section 8. Finite State 2442 Machine from the base draft?? The original reviewer said, yes, when 2443 Sue's FSM draft becomes a WG document, we should remove section 8 2444 from the base draft. Yakov asked that the AD's provide input on this 2445 suggestion. 2447 Alex responded saying that the FSM draft is going to be part of the 2448 base spec, and not another document once the FSM words are approved. 2450 2.43. Clarify the NOTIFICATION Section 2452 Status: Consensus 2453 Change: Yes 2454 Summary: Replace: 2456 "If a peer sends a NOTIFICATION message, and there is an error in 2457 that message, there is unfortunately no means of reporting this error 2458 via a subsequent NOTIFICATION message." 2460 With: 2462 If a peer sends a NOTIFICATION message, and the receiver of the 2463 message detects an error in that message, the receiver can not use a 2464 NOTIFICATION message to report this error back to the peer. 2466 Discussion: 2468 The "NOTIFICATION message error handling" thread proposed: 2470 Please change" "If a peer sends a NOTIFICATION message, and there is 2471 an error in that message, there is unfortunately no means of 2472 reporting this error via a subsequent NOTIFICATION message." 2474 To: "If a peer receives a NOTIFICATION message, and there is an error 2475 in that message, there is unfortunately no means of reporting this 2476 error via a subsequent NOTIFICATION message." 2478 This reversal of meaning met with disagreement, and this text was 2479 proposed instead: 2481 All errors detected while processing the NOTIFICATION message cannot 2482 be indicated by sending subsequent NOTIFICATION message back to 2483 originating peer, therefore there is no means of reporting 2484 NOTIFICATION message processing errors. Any error, such as an 2485 unrecognized Error Code or Error Subcode, should be noticed, logged 2486 locally, and brought to the attention of the administration of the 2487 peer that has sent the message. The means to do this, however, lies 2488 outside the scope of this document. 2490 The original posted agreed with the intent of the respondent's text, 2491 thought it was too wordy, but did not propose alternate text. 2493 Yakov replied with this proposed text: 2495 If a peer sends a NOTIFICATION message, and the receiver of the 2496 message detects an error in that message, the receiver can not use a 2497 NOTIFICATION message to report this error back to the peer. 2499 Two responses liked this new text. Unless there are objections, 2500 we'll consider that a consensus. 2502 2.44. Section 6.2: OPEN message error handling 2504 Status: Consensus 2505 Change: No 2506 Summary: One commenter observed that the spec seems to specify 2507 behavior that doesn't seem to be observed by extant implementations, 2508 and suggested modifications to the spec. They were later reminded 2509 that the base behavior is acceptable, and agreed. 2511 Discussion: 2513 The "BGP4 draft ; section 6.2" thread began with a discussion of 2514 section 6.2: OPEN message error handling. Specifically: 2516 "If one of the optional parameters in the Open message is not 2517 recognized, then the error subcode is set to 'unsupported optional 2518 parameters" 2519 We have hit on this line when we were testing a BGP connection 2520 between a speaker that supported capability negotiation and a speaker 2521 that did not. 2523 The speaker that did not support the negotiation closed down the 2524 peering session using the error clause mentioned above. Sometimes 2525 this lead to the other router to repeat the OPEN message with the 2526 Capability optional parameter; a game that went on for minutes. 2528 This router manufacturer stated in a reply to this that : "One should 2529 not close down the connection if an optional parameter is 2530 unrecognized. That would make this parameter basically mandatory. 2531 This is an well known error in the BGP spec. Neither Cisco or 2532 Juniper do this" 2534 If this is true it might be good to adapt the text. 2536 The response to this quoted RFC2842, Capabilities Advertisement with 2537 BGP-4: 2539 A BGP speaker determines that its peer doesn't support capabilities 2540 advertisement, if in response to an OPEN message that carries the 2541 Capabilities Optional Parameter, the speaker receives a NOTIFICATION 2542 message with the Error Subcode set to Unsupported Optional Parameter. 2543 In this case the speaker should attempt to re-establish a BGP 2544 connection with the peer without sending to the peer the Capabilities 2545 Optional Parameter. 2547 The original poster responded: 2549 This section from the Capabilities Advertisement RFC, is indeed 2550 inline with the section 6.2 of the BGP4 specification. For me 2551 however the question remains if most implementations do no simply 2552 ignore optional parameters that are unknown. And if so, if the text 2553 stated above reflects what is implemented by routers that do not have 2554 capability advertisement at all. 2556 Yakov replied to this with: 2558 RFC2842 assumes that a router (that doesn't implement RFC2842) would 2559 close the BGP session when the router receives an OPEN message with 2560 an unrecognized Optional Parameter. Therefore the text in the spec 2561 should be left unmodified. 2563 The original poster, Jonathan, agreed with this. This issue moves to 2564 consensus. 2566 2.45. Consistent References to BGP Peers/Connections/Sessions 2568 Status: Consensus 2569 Change: Yes 2570 Summary: Stick with "BGP Connection" as the consistent term. 2572 Discussion: 2574 Ben proposed and Yakov responded: 2576 > 1. Throughout the document we have various ways of naming the BGP 2577 > peering communication. 1) BGP Session, 2) BGP Peering Session, 2579 I'll replace "session" with "connection". 2581 > 3) TCP Connection, 2583 The spec doesn't name BGP peering communication as "TCP connection"; 2584 TCP connection is used to establish BGP connection. So, TCP 2585 connection and BGP connection are two different things. 2587 > 4) BGP Connection, 2589 The spec is going to use this term (see above). 2591 > 5) BGP Peering Connection, 2593 I'll replace "BGP peering connection" with "BGP connection". 2595 > 6) Connection, 2597 The text uses "connection" whenever it is clear from the context that 2598 it refers to "BGP connection" (or "TCP connection"). 2600 > 7) BGP Speaker Connection. 2602 I'll replace "BGP Speaker Connection" with "BGP connection". 2604 > > BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker 2606 The term "speaker" is used when it is clear from the context that we 2607 are talking about "BGP speaker". 2609 > 2. Change Internal peer to IBGP Peer. 2611 IBGP stands for "BGP connection between internal peers". Therefore 2612 the term "IBGP Peer" would mean "BGP connection between internal 2613 peers peer". That doesn't seem appropriate. 2615 This issue has had some discussion, and section 3 was referenced, 2616 specifically: 2618 Refer to Section 3 - Summary of operations which clearly states that 2619 " .. a peer in a different AS is referred to as an external peer, 2620 while a peer in the same AS may be described as an internal peer. 2621 Internal BGP and external BGP are commonly abbreviated IBGP and EBGP" 2623 After more discussion it was decided that we should modify a 2624 paragraph on page 4 to read: 2626 If a particular AS has multiple BGP speakers and is providing transit 2627 service for other ASs, then care must be taken to ensure a consistent 2628 view of routing within the AS. A consistent view of the interior 2629 routes of the AS is provided by the IGP used within the AS. For the 2630 purpose of this document, it is assumed that a consistent view of the 2631 routes exterior to the AS is provided by having all BGP speakers 2632 within the AS maintain IBGP with each other. Care must be taken to 2633 ensure that the interior routers have all been updated with transit 2634 information before the BGP speakers announce to other ASs that 2635 transit service is being provided. 2637 This change has consensus. 2639 > 3. Change External peer to EBGP Peer. 2641 Ditto. 2643 Alex responded that having explicit definitions would be nice. This 2644 ties into the general glossary suggestion (see issues 16, 34 & 36). 2646 He also suggested that: 2648 "BGP session" which works over a "TCP connection" would be closer to 2649 the terminology we're actually using now and would avoid possible 2650 confusions when people read terms like "Connection collision") 2652 This was discussed in the "Generial Editorial Comment" thread. 2654 After some further discussion, it was decided that, due to existing 2655 implementations, we should go with "BGP connection" as the consistent 2656 term. We are at consensus. 2658 2.46. FSM Connection Collision Detection 2660 Status: Consensus 2661 Change: Yes 2662 Summary: Add this to section 8: 2664 There is one FSM per connection. Prior to determining what peer a 2665 connection is associated with there may be two connections for a 2666 given peer. There should be no more than one connection per peer. 2667 The collision detection identifies the case where there is more than 2668 one connection per peer and provides guidance for which connection to 2669 get rid of. When this occurs, the corresponding FSM for the 2670 connection that is closed should be disposed of. 2672 Discussion: 2674 The original reviewer (Tom) commented that the base draft, FSM 2675 section, could use some clarification around the area of connection 2676 collision detection. Specifically, he argued that it seems like 2677 there are actually 2 FSM's depending on which one backs off in the 2678 case of a collision. He proposed this text to clear things up: 2680 "8 BGP Finite State Machine 2682 This section specifies BGP operation - between a BGP speaker and its 2683 peer over a single TCP connection - in terms of a Finite State 2684 Machine (FSM). Following is a brief summary ... "(as before) 2686 Instead of just 2688 "This section specifies BGP operation in terms of a Finite State 2689 Machine (FSM). Following is a brief summary ... "(as before). 2691 Curtis responded: 2693 There is one FSM per connection. Prior to determining what peer a 2694 connection is associated with there may be two connections for a 2695 given peer. There should be no more than one connection per peer. 2696 The collision detection identifies the case where there is more than 2697 one connection per peer and provides guidance for which connection to 2698 get rid of. When this occurs, the corresponding FSM for the 2699 connection that is closed should be disposed of. 2701 I'm not sure which document containing an FSM we should be reading at 2702 this point, but we could add the above paragraph if we need to 2703 explicitly state that the extra connection and its FSM is disposed of 2704 when a collision is detected. 2706 When a TCP accept occurs, a connection is created and an FSM is 2707 created. Prior to the point where the peer associated with the 2708 connection is known the FSM cannot be associated with a peer. The 2709 collision is a transient condition in which the rule of "one BGP 2710 session per peer" is temporarily violated and then corrected. 2712 This is discussed in the "FSM but FSM of what?" thread. 2714 Sue responded that she would be happy to add Curtis' text to section 2715 8 and solicited any additional comments. There was only one on 2716 capitalization, so this issue is at consensus. 2718 2.47. FSM - Add Explicit State Change Wording 2720 Status: Consensus 2721 Change: No 2722 Summary: A desire for explicit state change wording was expressed. 2723 No text was proposed. The assumption is that this issue has reached 2724 a happy conclusion. 2726 Discussion: 2728 The initial reviewer: 2730 In most places, the actions taken on the receipt of an event include 2731 what the new state will be or that it remains unchanged. But there 2732 are a significant number of places where this is not done (eg Connect 2733 state events 14, 15, 16). I would like to see consistency, always 2734 specify the new/unchanged state. Else I may be misreading it. 2736 There was a response asking for specific text, and offering to take 2737 the discussion private. 2739 This is discussed in the "FSM words - state changes" thread. 2741 There has been no further discussion on this. The assumption is that 2742 is has reached a happy conclusion privately. 2744 2.48. Explicitly Define Processing of Incoming Connections 2746 Status: Consensus 2747 Change: Yes 2748 Summary: Add text that is at the end of the discussion to section 8. 2750 Discussion: 2752 Alex suggested we explicitly define: 2754 - processing of incoming TCP connections (peer lookup, acceptance, 2755 FSM creation, collision control,) 2757 Curtis later proposed this text: 2759 BGP must maintain separate FSM for each configured peer. Each BGP 2760 peer paired in a potential connection will attempt to connect to the 2761 other. For the purpose of this discussions, the active or connect 2762 side of a TCP connection (the side sending the first TCP SYN packet) 2763 is called outgoing. The passive or listening side (the sender of the 2764 first SYN ACK) is called the an incoming connection. 2766 A BGP implementation must connect to and listen on TCP port 179 for 2767 incoming connections in addition to trying to connect to peers. For 2768 each incoming connection, a state machine must be instantiated. 2769 There exists a period in which the identity of the peer on the other 2770 end of an incoming connection is not known with certainty. During 2771 this time, both an incoming and outgoing connection for the same peer 2772 may exist. This is referred to as a connection collision (see 2773 Section x.x, was 6.8). 2775 A BGP implementation will have at most one FSM for each peer plus one 2776 FSM for each incoming TCP connection for which the peer has not yet 2777 been identified. Each FSM corresponds to exactly one TCP connection. 2779 Jonathan pointed out that there was an inaccuracy in the proposed 2780 text. Curtis replied with this: 2782 You're correct in that you must have a collision of IP addresses on 2783 the TCP connections and that the BGP Identifier is used only to 2784 resolve which gets dropped. 2786 The FSM stays around as long as "BGP Identifier" is not known. 2787 Replace "not known with certainty" with "known but the BGP identifier 2788 is not known" and replace "for the same peer" with "for the same 2789 configured peering". 2791 The first paragraph is unchanged: 2793 BGP must maintain separate FSM for each configured peer. Each BGP 2794 peer paired in a potential connection will attempt to connect to the 2795 other. For the purpose of this discussions, the active or connect 2796 side of a TCP connection (the side sending the first TCP SYN packet) 2797 is called outgoing. The passive or listening side (the sender of the 2798 first SYN ACK) is called the an incoming connection. 2800 The second paragraph becomes: 2802 A BGP implementation must connect to and listen on TCP port 179 for 2803 incoming connections in addition to trying to connect to peers. For 2804 each incoming connection, a state machine must be instantiated. 2805 There exists a period in which the identity of the peer on the other 2806 end of an incoming connection is known but the BGP identifier is not 2807 known. During this time, both an incoming and outgoing connection 2808 for the same configured peering may exist. This is referred to as a 2809 connection collision (see Section x.x, was 6.8). 2811 The next paragraph then needs to get fixed. Changed "for each peer" 2812 to "for each configured peering". 2814 A BGP implementation will have at most one FSM for each configured 2815 peering plus one FSM for each incoming TCP connection for which the 2816 peer has not yet been identified. Each FSM corresponds to exactly 2817 one TCP connection. 2819 Add a paragraph to further clarify the point you made. 2821 There may be more than one connection between a pair of peers if the 2822 connections are configured to use a different pair of IP addresses. 2823 This is referred to as multiple "configured peerings" to the same 2824 peer. 2826 > So multiple simultaneous BGP connection are allowed between the 2827 same two > peers, and this behavior is implemented, for example to do 2828 load balancing. 2830 Good point. 2832 I hope the corrections above cover your (entirely valid) objections. 2833 If you see any more errors please let me know. 2835 Tom replied that: 2837 I take issue with the 'will attempt to connect' which goes too far. 2839 The FSM defines events 4 and 5, 'with passive Transport 2840 establishment', so the system may wait and not attempt to connect. 2841 The exit from this state is either the receipt of an incoming TCP 2842 connection (SYN) or timer expiry. 2844 So we may have a FSM attempting to transport connect for a given 2845 source/destination IP pair or we may have an FSM not attempting to 2846 connect. (In the latter case, I do not think we can get a 2847 collision). In the latter case, an incoming connection should not 2848 generate an additional FSM. 2850 I do not believe the concept of active and passive is helpful since a 2851 given system can flip from one to the other and it does not help us 2852 to clarify the number of FSM involved.. 2854 And Curtis suggested that: 2856 Could this be corrected by replacing "will attempt to connect" with 2857 "unless configured to remain in the idle state, or configured to 2858 remain passive, will attempt to connect". We could also shorten that 2859 to "will attempt to connect unless configured otherwise". 2861 Clarification (perhaps an item for a glossary entry): The terms 2862 active and passive have been in our vocabulary for almost a decade 2863 and have proven useful. The words active and passive have slightly 2864 different meanings applied to a TCP connection or applied to a peer. 2865 There is only one active side and one passive side to any one TCP 2866 connection as per the definition below. When a BGP speaker is 2867 configured passive it will never attempt to connect. If a BGP 2868 speaker is configured active it may end up on either the active or 2869 passive side of the connection that eventually gets established. 2870 Once the TCP connection is completed, it doesn't matter which end was 2871 active and which end was passive and the only difference is which 2872 side of the TCP connection has port number 179. 2874 Tom agreed with Curtis, that he liked the "will attempt to connect 2875 unless configured otherwise" verbiage. 2877 This was discussed in the "Generial Editorial Comment" thread. 2879 Sue proposed we add the text above in section 8.2. It is summarized 2880 here for clarity: 2882 8.2) Description of FSM 2884 8.2.1) FSM connections 2886 (text below) 2888 8.2.2) FSM Definition 2890 (text now in 8.2) 2892 "BGP must maintain a separate FSM for each configured peer plus Each 2893 BGP peer paired in a potential connection unless configured to remain 2894 in the idle state, or configured to remain passive, will attempt to 2895 to connect to the other. For the purpose of this discussion, the 2896 active or connect side of the TCP connection (the side of a TCP 2897 connection (the side sending the first TCP SYN packet) is called 2898 outgoing. The passive or listening side (the sender of the first SYN 2899 ACK) is called an incoming connection. [See section on the terms 2900 active and passive below.] 2902 A BGP implementation must connect to and listen on TCP port 179 for 2903 incoming connections in addition to trying to connect to peers. Fro 2904 each incoming connection, a state machine must be instantiated. 2905 There exists a period in which the identity of the peer on the other 2906 end of an incoming connection is known but the BGP identifier is not 2907 known. During this time, both an incoming and an outgoing connection 2908 for the same configured peering may exist. This is referred to as a 2909 connection collision (see Section x.x, was 6.8). 2911 A BGP implementation will have at most one FSM for each configured 2912 peering plus one FSM for each incoming TCP connection for which the 2913 peer has not yet been identified. Each FSM corresponds to exactly 2914 one TCP connection. 2916 There may be more than one connections between a pair of peers if the 2917 connections are configured to use a different pair of IP addresses. 2918 This is referred to as multiple "configured peerings" to the same 2919 peer. 2921 8.2.1.1) Terms "active" and "passive" 2923 The terms active and passive have been in our vocabulary for almost a 2924 decade and have proven useful. The words active and passive have 2925 slightly different meanings applied to a TCP connection or applied to 2926 a peer. There is only one active side and one passive side to any 2927 one TCP connection per the definition above [and the state machine 2928 below.] When a BGP speaker is configured active it may end up on 2929 either the active or passive side of the connection that eventually 2930 gets established. Once the TCP connection is completed, it doesn't 2931 matter which end was active and which end was passive and the only 2932 difference is which side of the TCP connection has port number 179. 2934 For additional text, see issue 46. 2936 Sue solicited additional comments, the only one was on 2937 capitalization, so it would appear we are at consensus with this 2938 issue. 2940 2.49. Explicitly Define Event Generation 2942 Status: Consensus 2943 Change: No 2944 Summary: Suggested that we explicitly define BGP message processing. 2945 No text proposed. There has been no further discussion on this 2946 issue, it is assumed that the consensus is that things are ok the way 2947 they are. 2949 Discussion: 2951 Alex suggested we explicitly define: 2953 - generation of events while processing BGP messages, i.e., the text 2954 describing message processing should say where needed that a specific 2955 event for the BGP session should be generated. 2957 No text was proposed. 2959 This discussion has received no further comment. Unless someone 2960 wants to reopen it, it is assumed it has reached a happy ending. 2962 This was discussed in the "Generial Editorial Comment" thread. 2964 2.50. FSM Timers 2966 Status: Consensus 2967 Change: No 2968 Summary: Discussion tabled, because new document version rendered the 2969 discussion moot. 2971 Discussion: 2973 This discussion began with a suggestion that the timers currently in 2974 the FSM: 2976 In the 26 Aug text, I find the timer terminology still confusing. 2977 Timers can, I find, stop start restart clear set reset expire 2979 Can be cleaned up and simplified to: 2981 start with initial value (spell it out just to be sure) stop expire 2983 A response to this proposal was, that the existing set is clear, and 2984 that the proposed set is insufficiently rich to describe a concept 2985 like "reset" which encompasses: "Stop the timer, and reset it to its 2986 initial value." 2988 This discussion reached an impasse, when Sue pointed out that the 2989 text had been updated, and to please review the new text. 2991 This was discussed in the "FSM more words" thread. 2993 2.51. FSM ConnectRetryCnt 2995 Status: Consensus 2996 Change: No 2997 Summary: Discussion tabled, because new document version rendered the 2998 discussion moot. 3000 Discussion: 3002 This started with the observation that the ConnectRetryCnt "seems to 3003 have lost its purpose." It was suggested that this be made a Session 3004 Attribute, along with: OpenDelayTimer and DelayOpenFlag. 3006 Curtis explained that the current purpose of the ConnectRetryCnt is 3007 something to be read by the MIB. He also advocated against adding 3008 the additional Session Attributes. 3010 2.52. Section 3: Keeping routes in Adj-RIB-In 3012 Status: Consensus 3013 Change: Yes 3014 Summary: Add: To allow local policy changes to have the correct 3015 effect without resetting any BGP connections, a BGP speaker SHOULD 3016 either (a) retain the current version of the routes advertised to it 3017 by all of its peers for the duration of the connection, or (b) make 3018 use of the Route Refresh extension [12]. 3020 Discussion: 3022 This thread started with a question about why we should retain routes 3023 in the Adj-RIB-In, and how it relates to the Route Refresh extension. 3025 mrr proposed this text: 3027 ... Therefore, a BGP speaker must either retain the current version 3028 of the routes advertised by all of its peers for the duration of the 3029 connection, or make use of the Route Refresh extension [12]. This is 3030 necessary to allow local policy changes to have the correct effect 3031 without requiring the reset of any peering sessions. 3033 If the implementation decides not to retain the current version of 3034 the routes that have been received from a peer, then Route Refresh 3035 messages should be sent whenever there is a change to local policy. 3037 Yakov later suggested this text, with a slight rewording: 3039 To allow local policy changes to have the correct effect without 3040 resetting any BGP connections, a BGP speaker SHOULD either (a) retain 3041 the current version of the routes advertised to it by all of its 3042 peers for the duration of the connection, or (b) make use of the 3043 Route Refresh extension [12]. 3045 mrr responded that he was fine with Yakov's suggestions. 3047 This was discussed in the "Proxy: comments on section 3" thread. 3049 2.53. Section 4.3 - Routes v. Destinations - Advertise 3051 Status: Consensus 3052 Change: No 3053 Summary: The text that has reached consensus in issue 54 also 3054 addresses this issue. 3056 Discussion: 3058 This issue arose out of this question to the list: 3060 Since: 3062 "For the purpose of this protocol, a route is defined as a unit of 3063 information that pairs a set of destinations with the attributes of a 3064 path to those destinations. The set of destinations are the systems 3065 whose IP addresses are reported in the Network Layer Reachability 3066 Information (NLRI) field and the path is the information reported in 3067 the path attributes field of the same UPDATE message." 3069 When I read section 4.3: 3071 "An UPDATE message is used to advertise feasible routes sharing 3072 common path attribute to a peer, or to withdraw multiple unfeasible 3073 routes from service (see 3.1)." 3075 Shouldn't the text read "... advertise feasible [prefixes | 3076 destinations] sharing common path attribute(S)to a peer ...", 3077 because: 3079 1) A route is defined as quoted above from section 3.1? 3081 or since ... 3083 "An UPDATE message can advertise at most one set of path attributes, 3084 but multiple destinations ..." 3086 2) make "routes" in the original singular. 3088 This was discussed in the "Review Comments: Section 4.3: "routes" vs. 3089 destinations - advertise" thread. 3091 The text that has reached consensus in issue 54 also addresses this 3092 issue. 3094 2.54. Section 4.3 - Routes v. Destinations - Withdraw 3096 Status: Consensus 3097 Change: Yes 3098 Summary: Change the definition of "route" as it currently stands to: 3100 For the purpose of this protocol, a route is defined as a unit of 3101 information that pairs a set of destinations with the attributes of a 3102 path to those destinations. The set of destinations are systems 3103 whose IP addresses are contained in one IP address prefix carried in 3104 the Network Layer Reachability Information (NLRI) field of an UPDATE 3105 message and the path is the information reported in the path 3106 attributes field of the same UPDATE message. 3108 Multiple routes that have the same path attributes can be advertised 3109 in a single UPDATE message by including multiple prefixes in the NLRI 3110 field of the UPDATE message. 3112 Discussion: 3114 This issue was brought up with this question: 3116 When I read these two paragraphs at the end of section 4.3: 3118 "An UPDATE message can list multiple routes to be withdrawn from 3119 service. Each such route is identified by its destination (expressed 3120 as an IP prefix), which unambiguously identifies the route in the 3121 context of the BGP speaker - BGP speaker connection to which it has 3122 been previously advertised. 3124 An UPDATE message might advertise only routes to be withdrawn from 3125 service, in which case it will not include path attributes or Network 3126 Layer Reachability Information. Conversely, it may advertise only a 3127 feasible route, in which case the WITHDRAWN ROUTES field need not be 3128 present." 3130 It reads as if one must withdraw the _set of destinations_ advertised 3131 with the route instead of just one or more destinations since route 3132 is defined in section 3.1 as: 3134 "For the purpose of this protocol, a route is defined as a unit of 3135 information that pairs a set of destinations with the attributes of a 3136 path to those destinations. The set of destinations are the systems 3137 whose IP addresses are reported in the Network Layer Reachability 3138 Information (NLRI) field and the path is the information reported in 3139 the path attributes field of the same UPDATE message." 3141 Shouldn't the text change "routes" to destinations, or to prefixes? 3142 The original commenter added this clarification later: 3144 I meant to say, the *same* set of destinations as those advertised 3145 initially. For example, NLRI with dest-a, dest-b and dest-c with the 3146 same attributes is a "route". The withdrawal of the "route" can be 3147 read as one must withdraw all destinations originally advertised for 3148 that route (dest-a, dest-b, dest-c) as a unit. 3150 A first time reader could be left wondering if the above must be the 3151 case, or it is valid for an implementation to withdraw just one of 3152 these destinations (e.g. dest-b), leaving the others (dest-a, dest-c) 3153 reachable with their attributes intact. 3155 If there is no relationship between destinations when advertised as a 3156 set of destinations in a route and those destinations that can be 3157 withdrawn should be explicitly stated. Otherwise, the draft should 3158 call out that it is not legal to withdraw one prefix only in the set 3159 of prefixes advertised as previously as route. 3161 Matt suggested that since the definition seems to cause some 3162 confusion, that we update the definition to: 3164 "For the purpose of this protocol, a route is defined as a unit of 3165 information that pairs a set of destinations with the attributes of a 3166 path to those destinations. The set of destinations are systems 3167 whose IP addresses are reported in one prefix present in the Network 3168 Layer Reachability Information (NLRI) field of an UPDATE and the path 3169 is the information reported in the path attributes field of the same 3170 UPDATE message. 3172 This definition allows multiple routes to be advertised in a single 3173 UPDATE message by including multiple prefixes in the NLRI field of 3174 the UPDATE. All such prefixes must be associated with the same set 3175 of path attributes." 3177 Yakov suggested some minor rewording: 3179 For the purpose of this protocol, a route is defined as a unit of 3180 information that pairs a set of destinations with the attributes of a 3181 path to those destinations. The set of destinations are systems 3182 whose IP addresses are contained in one IP address prefix carried in 3183 the Network Layer Reachability Information (NLRI) field of an UPDATE 3184 message and the path is the information reported in the path 3185 attributes field of the same UPDATE message. 3187 Multiple routes that have the same path attributes can be advertised 3188 in a single UPDATE message by including multiple prefixes in the NLRI 3189 field of the UPDATE message. 3191 Both Jeff and Matt responded that they liked this text. 3193 2.55. Section 4.3 - Description of AS_PATH length 3195 Status: Consensus 3196 Change: Yes 3197 Summary: Replace: 3199 Path segment length is a 1-octet long field containing the number of 3200 ASs in the path segment value field. 3202 With: 3204 Path segment length is a 1-octet long field containing the number of 3205 ASs (not the number of octets) in the path segment value field. 3207 Discussion: 3209 This question was raised: 3211 Length fields elsewhere in the draft specify the number of bytes that 3212 a variable length field uses. For AS_PATH, length is used as the 3213 number of 2 byte AS numbers. In the interest of not having to check 3214 other sources to be sure, should the description of path segment 3215 value: 3217 "The path segment value field contains one or more AS numbers, each 3218 encoded as a 2-octets long field." 3220 explicitly mention the number of bytes used by the variable length 3221 field? 3223 Or, make the description of length explicitly mention that it is not 3224 the length of the variable length field as is the case with other 3225 length fields? 3227 One response to this agreed that some more clarification would be 3228 good, specifically an ASCII art diagram. No diagram was proposed. 3230 Yakov proposed this change: 3232 How about replacing 3234 Path segment length is a 1-octet long field containing the number of 3235 ASs in the path segment value field. 3237 with the following 3238 Path segment length is a 1-octet long field containing the number of 3239 ASs (but not the number of octets) in the path segment value field. 3241 Jonathan offered this text: 3243 How about: "Path segment length is a 1-octet long field containing 3244 the number of ASs (which is half the number of octets since each AS 3245 is 2 octets) in the path segment value field (also note that the path 3246 may contain more than 1 segment). 3248 Jeff replied that he preferred Yakov's text, but without the "but". 3249 Yakov agreed to that. Andrew also agreed, and asked if there were 3250 any objections to moving this issue into consensus. There were no 3251 objections. 3253 2.56. Section 6 - BGP Error Handling 3255 Status: Consensus 3256 Change: Yes 3257 Summary: There are a variety of updates to the text that are best 3258 described in the discussion section. 3260 Discussion: 3262 This discussion began with some suggestions on ways to clarify the 3263 text in section 6 dealing with error handling. The original 3264 comments, and Yakov's response are below: 3266 > At the beginning of Section 6. BGP Error Handling: 3267 > 3268 > 3269 > "When any of the conditions described here are detected, a 3270 > NOTIFICATION message with the indicated Error Code, Error Subcode, 3271 > and Data fields is sent, and the BGP connection is closed." 3272 > 3273 > There are several cases where the conditions described in this 3274 section 3275 > do not result in the BGP connection being closed. These conditions 3276 > should either state that the connection stays up. Another 3277 possibility 3278 > is to remove "and the BGP connection is closed." above, and for 3279 each 3280 > listed connection, state what happens to the BGP connection. This 3281 > already takes place for certain conditions, but isn't done 3282 consistently. 3284 How about replacing the above with the following: 3286 When any of the conditions described here are detected, a 3287 NOTIFICATION message with the indicated Error Code, Error Subcode, 3288 and Data fields is sent, and the BGP connection is closed, unless it 3289 is explicitly stated that no NOTIFICATION message is to be sent and 3290 the BGP connection is not to be close. 3292 > I tried to list what I found (which may be wrong or incomplete) 3293 below: 3294 > 3295 > 3296 > "If the NEXT_HOP attribute is semantically incorrect, the error 3297 should 3298 > be logged, and the route should be ignored. In this case, no 3299 > NOTIFICATION message should be sent." 3300 > 3301 > * Append the connection is not closed. 3303 Done. 3305 > 3306 > "(a) discard new address prefixes from the neighbor, or (b) 3307 terminate 3308 > the BGP peering with the neighbor." 3309 > 3310 > * Append "the connection is not closed" to case (a) 3312 added "(while maintaining BGP peering with the neighbor)" to case 3313 (a). 3315 > 3316 > "If the autonomous system number appears in the AS path the 3317 > route may be stored in the Adj-RIB-In," 3318 > 3319 > * append and the BGP connection stays up. 3320 > 3321 > "but unless the router is configured to accept routes with its 3322 > own autonomous system in the AS path, the route shall not be 3323 > passed to the BGP Decision Process." 3325 I would suggest to move this text to Section 9 (UPDATE message 3326 handling), as receiving a route with your own AS in the AS path isn't 3327 really an error. It is just that usually (but not always) you can't 3328 put this route in your Adj-RIB-In. 3330 > * Q1) does the BGP connection stay up? 3332 yes. 3334 > * Q2) what if the router isn't configured to accept routes with its 3335 > own AS in the AS path? One _may_ store the route in Adj-RIB-In, 3336 but 3337 > if one doesn't want to? 3339 So, don't store them. 3341 > Is the BGP connection closed? If so, what subcode? 3343 The connection is *not* closed. 3345 > "If an optional attribute is recognized, then the value of this 3346 > attribute is checked. If an error is detected, the attribute is 3347 > discarded, and the Error Subcode is set to Optional Attribute 3348 Error. 3349 > The Data field contains the attribute (type, length and value)." 3350 > 3351 > * Append and the BGP connection stays up after "the attribute is 3352 discarded". 3354 Since you have to close the connection, you have to discard all the 3355 routes received via this connection, including the route with the 3356 incorrect attribute. So, there is no need to say that "the attribute 3357 is discarded". 3359 There have been no objections to the updates listed above. This 3360 issue seems to have reached a happy ending, so it has been moved into 3361 consensus. 3363 This was discussed in the "-17 review Section 6 - BGP Error 3364 Handling." thread. 3366 2.57. Section 6.2 - Hold timer as Zero 3368 Status: Consensus 3369 Change: No 3370 Summary: It was suggested that we update the text to say that we MUST 3371 reject hold time values of zero. It was pointed out that this is not 3372 the case and the text should say the way it is. 3374 Discussion: 3376 In Section 6.2 on OPEN message error handling: 3378 If the Hold Time field of the OPEN message is unacceptable, then the 3379 Error Subcode MUST be set to Unacceptable Hold Time. An 3380 implementation MUST reject Hold Time values of one or two seconds. 3382 I feel that text similar to: 3384 "An implementation MUST also reject Hold Time values of zero received 3385 from a peer in a different AS" should be considered for completeness. 3387 A number of respondents pointed out that zero hold time is legitimate 3388 under certain circumstances. 3390 This was discussed in the "-17 review, Section 6.2 - must reject hold 3391 time" thread. 3393 2.58. Deprecation of ATOMIC_AGGREGATE 3395 Status: Consensus 3396 Change: Yes 3397 Summary: For new text, please see the end of the discussion. 3399 Discussion: 3401 Jeff opened this discussion with: 3403 Deprecation of ATOMIC_AGGREGATE: 3405 [This is a summary of some discussions from those who have "been 3406 there, done that" during the CIDR deployment period and also comments 3407 from network operators on the NANOG list.] 3409 When BGP-4 was originally drafted, the topic of aggregation was new 3410 enough that people didn't exactly know how it would be used. 3411 Additionally, there were some transition issues when aggregated 3412 networks would need to be de-aggregated and re-advertised into a 3413 classful routing mesh such as BGP-3. 3415 The ATOMIC_AGGREGATE flag was intended to prevent a route from being 3416 de-aggregated when de-aggregation would introduce routing loops. 3417 Note that de-aggregation in this context specifically means making a 3418 less specific route into one or more more-specific routes. 3420 The current BGP draft has two situations where ATOMIC_AGGREGATE 3421 should be appended to a route: 1. When a route's AS_PATH is 3422 intentionally truncated, such as what happens by default on Cisco's, 3423 or using the "brief" option on GateD. Juniper has a similar feature 3424 - I'm unsure of the default. 2. When two routes are implicitly 3425 aggregated in the LocRib such that a more specific route is not 3426 selected when a less specific route is from a given peer. 3428 Note that this particular feature is not implemented anywhere that I 3429 am aware of. 3431 3. There is a third case not covered by the specification: Implicit 3432 aggregation on export - a more specific route is not exported and 3433 only a less specific one is. 3435 When network operators were asked about de-aggregation practices, I 3436 received about 40 responses. The majority of these responses 3437 confused de-aggregation with leaking existing more-specific routes 3438 that are used internally rather than explicitly de-aggregating a 3439 less-specific route. 3441 There were a very few cases of explicit de-aggregation. One form was 3442 done for purposes of dealing with another ISP creating a routing DoS 3443 by advertising IP space that didn't belong to them - leaked more 3444 specifics alleviated the problem in many cases. (Note that this is a 3445 security issue in the routing system.) 3447 The second case was de-aggregating routes internally (and sending the 3448 routes via IBGP marked with NO-ADVERTISE) for purposes of traffic 3449 engineering routing internally where a given upstream failed to 3450 provide enough routing information to allow traffic flows to be 3451 optimized based on supplied prefixes. 3453 My conclusions to this are: 1. De-aggregation is not a common 3454 practice. 2. It is no longer a major concern since classful inter- 3455 domain routing is pretty much gone. 3. The spec doesn't match 3456 reality and should be corrected. 3458 My suggestions are thus this: Section 5.1.6 should be updated as 3459 follows: ATOMIC_AGGREGATE is a well-known discretionary attribute. 3460 Its use is deprecated. 3462 When a router explicitly aggregates several routes for the purpose of 3463 advertisement to a particular peer, and the AS_PATH of the aggregated 3464 route excludes at least some of the AS numbers present in the AS_PATH 3465 of the routes that are aggregated (usually due to truncation), the 3466 aggregated route, when advertised to the peer, MUST include the 3467 ATOMIC_AGGREGATE attribute. 3469 Section 9.1.4 should be updated as follows: 3470 Original text: If a BGP speaker receives overlapping routes, the 3471 Decision Process MUST consider both routes based on the configured 3472 acceptance policy. If both a less and a more specific route are 3473 accepted, then the Decision Process MUST either install both the less 3474 and the more specific routes or it MUST aggregate the two routes and 3475 install the aggregated route, provided that both routes have the same 3476 value of the NEXT_HOP attribute. 3478 If a BGP speaker chooses to aggregate, then it MUST add 3479 ATOMIC_AGGREGATE attribute to the route. A route that carries 3480 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3481 NLRI of this route can not be made more specific. Forwarding along 3482 such a route does not guarantee that IP packets will actually 3483 traverse only ASs listed in the AS_PATH attribute of the route. 3485 Replace with: 3487 It is common practice that more specific routes are often implicitly 3488 aggregated by selecting or advertising only a less-specific route 3489 when overlapping routes are present. As such, all routes SHOULD be 3490 treated as if ATOMIC_AGGREGATE is present and not be made more 3491 specific (de-aggregated). De-aggregation may lead to routing loops. 3493 Section 9.2.2 should remain as it is. 3495 Implications of not making the above updates: 3496 ATOMIC_AGGREGATE is not implemented as documented. Current 3497 operational practices do not seem to often trigger situations that it 3498 was intended to re-mediate. After all, by the way it is currently 3499 documented, many of the routes in the Internet would likely have 3500 ATOMIC_AGGREGATE. 3502 The original motivation for this investigation (aside from a few 3503 years of wondering what this portion of the spec *really* meant) was 3504 making sure the MIB is correctly documented. I can do this now, even 3505 if the spec is not corrected by simply noting that the values: 3506 lessSpecificRouteNotSelected(1), 3507 lessSpecificRouteSelected(2) 3509 mean: 3510 ATOMIC_AGGREGATE not present 3511 ATOMIC_AGGREGATE present 3513 rather than documenting anything about less and more specific routes. 3515 The v2MIB can be fixed to just call it what it is since it hasn't 3516 been RFC'ed yet. 3518 Lastly, the spec would just be incorrect. But all said, nothing bad 3519 would really come of this. 3521 Yakov responded to this, saying that he thought these changes were 3522 reasonable, and unless there were objections, they would be adopted. 3524 Ishi strongly agreed with the changes. 3526 Curtis stated that: 3528 We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated 3529 rather than replaced with an AS_SET. It was always purely 3530 informational since no one intentionally deaggregated and 3531 reannounced. 3533 And suggested that we remove the MUSTs and indicated that this is 3534 only informational. 3536 Jeff replied that: 3538 The point is that by definition of the attribute, anywhere that 3539 policy is used (and some places where it may not be), 3540 ATOMIC_AGGREGATE *should* be there. Since its not, and it would 3541 generally be everywhere, you just shouldn't de-aggregate. 3543 At best, leaving it as a method of informationally signalling 3544 truncation of a AS_PATH is the best we'll get out of it - and it 3545 matches current implementations. 3547 Jonathan agreed with Curtis' idea that we should just move 3548 ATOMIC_AGGREGATE to informational. 3550 Curtis proposed this text: 3552 This existing text is fine: 3554 f) ATOMIC_AGGREGATE (Type Code 6) 3556 ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0. 3557 Usage of this attribute is described in 5.1.6. 3559 This is the existing text that we are considering changing: 3561 5.1.6 ATOMIC_AGGREGATE 3563 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3565 When a router aggregates several routes for the purpose of 3566 advertisement to a particular peer, and the AS_PATH of the aggregated 3567 route excludes at least some of the AS numbers present in the AS_PATH 3568 of the routes that are aggregated, the aggregated route, when 3569 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3571 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3572 attribute MUST NOT remove the attribute from the route when 3573 propagating it to other speakers. 3575 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3576 attribute MUST NOT make any NLRI of that route more specific (as 3577 defined in 9.1.4) when advertising this route to other BGP speakers. 3579 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3580 attribute needs to be cognizant of the fact that the actual path to 3581 destinations, as specified in the NLRI of the route, while having the 3582 loop-free property, may not be the path specified in the AS_PATH 3583 attribute of the route. 3585 Suggested new text: 3587 5.1.6 ATOMIC_AGGREGATE 3589 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3591 When a router aggregates several routes for the purpose of 3592 advertisement to a particular peer, the AS_PATH of the aggregated 3593 route normally includes an AS_SET formed from the set of AS from 3594 which the aggregate was formed. In many cases the network 3595 administrator can determine that the aggregate can safely be 3596 advertised without the AS_SET and not form route loops. 3598 If an aggregate excludes at least some of the AS numbers present in 3599 the AS_PATH of the routes that are aggregated as a result of dropping 3600 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3601 include the ATOMIC_AGGREGATE attribute. 3603 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3604 attribute SHOULD NOT remove the attribute from the route when 3605 propagating it to other speakers. 3607 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3608 attribute MUST NOT make any NLRI of that route more specific (as 3609 defined in 9.1.4) when advertising this route to other BGP speakers. 3611 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3612 attribute needs to be cognizant of the fact that the actual path to 3613 destinations, as specified in the NLRI of the route, while having the 3614 loop-free property, may not be the path specified in the AS_PATH 3615 attribute of the route. 3617 Diffs (for reader convenience): 3619 @@ -4,13 +4,19 @@ ATOMIC_AGGREGATE is a well-known discretionary 3620 attribute. 3622 When a router aggregates several routes for the purpose of 3623 - advertisement to a particular peer, and the AS_PATH of the 3624 - aggregated route excludes at least some of the AS numbers 3625 - present in the AS_PATH of the routes that are aggregated, 3626 - the aggregated route, when advertised to the peer, MUST 3627 - include the ATOMIC_AGGREGATE attribute. 3628 + advertisement to a particular peer, the AS_PATH of the 3629 + aggregated route normally includes an AS_SET formed from the 3630 + set of AS from which the aggregate was formed. In many cases 3631 + the network administrator can determine that the aggregate can 3632 + safely be advertised without the AS_SET and not form route loops. 3633 + 3634 + If an aggregate excludes at least some of the AS numbers present 3635 + in the AS_PATH of the routes that are aggregated as a result of 3636 + dropping the AS_SET, the aggregated route, when advertised to the 3637 + peer, SHOULD include the ATOMIC_AGGREGATE attribute. 3639 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3640 - attribute MUST NOT remove the attribute from the route when 3641 + attribute SHOULD NOT remove the attribute from the route when 3642 + propagating it to other speakers. 3644 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3646 Current text in 9.1.4: 3648 If a BGP speaker chooses to aggregate, then it MUST add 3649 ATOMIC_AGGREGATE attribute to the route. A route that carries 3650 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3651 NLRI of this route can not be made more specific. Forwarding along 3652 such a route does not guarantee that IP packets will actually 3653 traverse only ASs listed in the AS_PATH attribute of the route. 3655 Change to: 3657 If a BGP speaker chooses to aggregate, then it SHOULD either include 3658 all AS used to form the aggregate in an AS_SET or add the 3659 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3660 primarily informational. With the elimination of IP routing 3661 protocols that do not support classless routing and the elimination 3662 of router and host implementations that do not support classless 3663 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3664 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3665 particular MUST NOT be de-aggregated. That is, the NLRI of this 3666 route can not be made more specific. Forwarding along such a route 3667 does not guarantee that IP packets will actually traverse only ASs 3668 listed in the AS_PATH attribute of the route. 3670 This text in 9.2.2.2 need not change. 3672 ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has 3673 ATOMIC_AGGREGATE path attribute, then the aggregated route shall have 3674 this attribute as well. 3676 The appendix need not change: 3678 Appendix 1. Comparison with RFC1771 3680 [...] 3682 Clarifications to the use of the ATOMIC_AGGREGATE attribute. 3684 This might be a bit more wordy that is necessary. It does address 3685 the objections to keeping ATOMIC_AGGREGATE by making the MUST into 3686 SHOULD, and explaining that ATOMIC_AGGREGATE is now primarily 3687 informational. 3689 Yakov was fine with this text. 3691 Yakov posted the text that represents the WG consensus: 3693 Replace: 3695 5.1.6 ATOMIC_AGGREGATE 3697 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3699 When a router aggregates several routes for the purpose of 3700 advertisement to a particular peer, and the AS_PATH of the aggregated 3701 route excludes at least some of the AS numbers present in the AS_PATH 3702 of the routes that are aggregated, the aggregated route, when 3703 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3705 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3706 attribute MUST NOT remove the attribute from the route when 3707 propagating it to other speakers. 3709 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3710 attribute MUST NOT make any NLRI of that route more specific (as 3711 defined in 9.1.4) when advertising this route to other BGP speakers. 3713 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3714 attribute needs to be cognizant of the fact that the actual path to 3715 destinations, as specified in the NLRI of the route, while having the 3716 loop-free property, may not be the path specified in the AS_PATH 3717 attribute of the route. 3719 with: 3721 5.1.6 ATOMIC_AGGREGATE 3723 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3725 When a router aggregates several routes for the purpose of 3726 advertisement to a particular peer, the AS_PATH of the aggregated 3727 route normally includes an AS_SET formed from the set of AS from 3728 which the aggregate was formed. In many cases the network 3729 administrator can determine that the aggregate can safely be 3730 advertised without the AS_SET and not form route loops. 3732 If an aggregate excludes at least some of the AS numbers present in 3733 the AS_PATH of the routes that are aggregated as a result of dropping 3734 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3735 include the ATOMIC_AGGREGATE attribute. 3737 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3738 attribute SHOULD NOT remove the attribute from the route when 3739 propagating it to other speakers. 3741 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3742 attribute MUST NOT make any NLRI of that route more specific (as 3743 defined in 9.1.4) when advertising this route to other BGP speakers. 3745 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3746 attribute needs to be cognizant of the fact that the actual path to 3747 destinations, as specified in the NLRI of the route, while having the 3748 loop-free property, may not be the path specified in the AS_PATH 3749 attribute of the route. 3751 In 9.1.4 replace: 3753 If a BGP speaker chooses to aggregate, then it MUST add 3754 ATOMIC_AGGREGATE attribute to the route. A route that carries 3755 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3756 NLRI of this route can not be made more specific. Forwarding along 3757 such a route does not guarantee that IP packets will actually 3758 traverse only ASs listed in the AS_PATH attribute of the route. 3760 with: 3762 If a BGP speaker chooses to aggregate, then it SHOULD either include 3763 all AS used to form the aggregate in an AS_SET or add the 3764 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3765 primarily informational. With the elimination of IP routing 3766 protocols that do not support classless routing and the elimination 3767 of router and host implementations that do not support classless 3768 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3769 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3770 particular MUST NOT be de-aggregated. That is, the NLRI of this 3771 route can not be made more specific. Forwarding along such a route 3772 does not guarantee that IP packets will actually traverse only ASs 3773 listed in the AS_PATH attribute of the route. 3775 This met with agreement. This issue is at consensus. 3777 2.59. Section 4.3 - Move text 3779 Status: Consensus 3780 Change: Yes (minimal) 3781 Summary: Update indentation to allow a new "subsection" heading. 3782 Otherwise no change. 3784 Discussion: 3786 This began with this suggestion: 3788 The text about the minimum length, at first look, gives the 3789 impression that it is still part of the NLRI field description and/or 3790 the Path Attributes section. A new "subsection" or heading of some 3791 sort would be helpful in switching context back to the UPDATE message 3792 as a whole and not the path attributes field anymore. 3794 Yakov agreed to update the indentation. 3796 Jonathan agreed, and suggested this text: 3798 " The minimum length of the UPDATE message is 23 octets -- 19 octets 3799 for the fixed header + 2 octets for the Withdrawn Routes Length + 2 3800 octets for the Total Path Attribute Length (the value of Withdrawn 3801 Routes Length is 0 and the value of Total Path Attribute Length is 3802 0)." 3804 Should be moved up to just after 3806 "... the Total Path Attribute Length field and the Withdrawn Routes 3807 Length field." 3809 Yakov responded to this with: 3811 Disagree, as "... the Total Path Attribute Length field and the 3812 Withdrawn Routes Length field." explains how to calculate the length 3813 of NLRI field (and therefore is part of the NLRI field description), 3814 while "The minimum length of the UPDATE message is 23 octets...." has 3815 to do with the length of the UPDATE message. 3817 Jonathan also suggested: 3819 " the value of Withdrawn Routes Length is 0 and the value of Total 3820 Path Attribute Length is 0)." 3822 Should be changed to 3824 " the min. value of Withdrawn Routes Length is 0 and the min. value 3825 of Total Path Attribute Length is 0)." 3827 And Yakov responded with: 3829 Disagree, as the text doesn't talk about what is the minimum value of 3830 the Withdrawn Routes Length and Total Path Attribute Length fields, 3831 but talks about the value of these fields in the case of a min length 3832 UPDATE message. 3834 After Yakov's response and a posting to the list asking that this be 3835 moved to consensus, there were no objections, so this is moved to 3836 consensus. 3838 This is discussed in the "Review: Comments: Section 4.3: UPDATE min 3839 length" thread. 3841 2.60. Section 4.3 - Path Attributes 3843 Status: Consensus 3844 Change: Yes 3845 Summary: Make this change to clarify path attributes in an UPDATE: 3847 To correct the confusion I propose to replace: 3849 A variable length sequence of path attributes is present in every 3850 UPDATE. 3852 with: 3854 A variable length sequence of path attributes is present in every 3855 UPDATE message, except for an UPDATE message that carries only the 3856 withdrawn routes. 3858 Discussion: 3860 This thread began with MikeC pointing out: 3862 The top of page 13 says: 3864 "A variable length sequence of path attributes is present in every 3865 UPDATE." 3867 Is this really true, given that later, in the second to last 3868 paragraph of this section (4.3): 3870 "An UPDATE message might advertise only routes to be withdrawn from 3871 service, in which case it will not include path attributes or Network 3872 Layer Reachability Information." 3874 This could be confusing to a first time reader. 3876 The path attribute length is present in every UPDATE, the path 3877 attribute field itself can be left out, both according to the 3878 description of the minimum length of the UPDATE message and 3879 (implied?) in the picture of the UPDATE message at the beginning of 3880 section 4.3. 3882 This met with one agreement. 3884 Yakov then proposed that: 3886 To correct the confusion I propose to replace: 3888 A variable length sequence of path attributes is present in every 3889 UPDATE. 3891 with: 3893 A variable length sequence of path attributes is present in every 3894 UPDATE message, except for an UPDATE message that carries only the 3895 withdrawn routes. 3897 There was one agreement with this proposal. 3899 This is discussed in the thread: "Review: Section 4.3 - Path 3900 Attributes" 3902 2.61. Next Hop for Redistributed Routes 3904 Status: Consensus 3905 Change: Yes 3906 Summary: More clearly specify the behavior of NEXT_HOP modification, 3907 for the text see the end of the discussion. 3909 Discussion: 3911 Jonathan began this thread with: 3913 I propose adding: 3915 "When announcing a locally originated route to an internal peer, the 3916 BGP speaker should use as the NEXT_HOP the interface address of the 3917 router through which the announced network is reachable for the 3918 speaker; if the route is directly connected to the speaker, or the 3919 interface address of the router through which the announced network 3920 is reachable for the speaker is the internal peer's address, then the 3921 BGP speaker should use for the NEXT_HOP attribute its own IP address 3922 (the address of the interface that is used to reach the peer)." 3924 AFTER 3926 "When sending a message to an internal peer, the BGP speaker should 3927 not modify the NEXT_HOP attribute, unless it has been explicitly 3928 configured to announce its own IP address as the NEXT_HOP." 3930 There has been no discussion on this. 3932 This is discussed in the "Next hop for redistributed routes" thread. 3934 Issue 14 closed in favor of this issue. 3936 In response to Yakov's call for input, Michael responded that: 3938 Section 5.1.3 explicitly states what to do when originating to an 3939 external peer. #2 covers one hop away, #3 covers more than on hop 3940 away. #1 talks about sending to an iBGP peer, but only when 3941 propagating a route received from an eBGP peer. 3943 1) When sending a message to an internal peer, the BGP speaker should 3944 not modify the NEXT_HOP attribute, unless it has been explicitly 3945 configured to announce its own IP address as the NEXT_HOP. 3947 Text similar to #2 should be added, in their own bullet items to #1 3948 such as what was suggested by Jonathan Natale (text is above.) 3950 Yakov replied with this: 3952 Replace: 3954 1) When sending a message to an internal peer, the BGP speaker should 3955 not modify the NEXT_HOP attribute, unless it has been explicitly 3956 configured to announce its own IP address as the NEXT_HOP. 3958 with: 3960 1) When sending a message to an internal peer, if the route is not 3961 locally originated the BGP speaker should not modify the NEXT_HOP 3962 attribute, unless it has been explicitly configured to announce its 3963 own IP address as the NEXT_HOP. When announcing a locally originated 3964 route to an internal peer, the BGP speaker should use as the NEXT_HOP 3965 the interface address of the router through which the announced 3966 network is reachable for the speaker; if the route is directly 3967 connected to the speaker, or the interface address of the router 3968 through which the announced network is reachable for the speaker is 3969 the internal peer's address, then the BGP speaker should use for the 3970 NEXT_HOP attribute its own IP address (the address of the interface 3971 that is used to reach the peer). 3973 And stated the change would be made if there were no objections. 3974 There have been no objections, so this is at consensus. 3976 2.62. Deprecate BGP Authentication Optional Parameter from RFC1771 3978 Status: Consensus 3979 Change: Yes 3980 Summary: We are at consensus, in that we agree that we should 3981 deprecate the BGP Authentication Optional Parameter as described in 3982 RFC1771 in favor of the mechanism described in RFC2385. The textual 3983 changes are listed at the end of the discussion section of this 3984 issue. 3986 Discussion: 3988 This discussion started in issue 21: Authentication Text Update. 3990 This topic has come up before (July time frame), but was recently 3991 refreshed in the context of issue 21. It began with some questions 3992 to the list as to who used what sort of authentication mechanisms. 3993 From the responses it was clear that MD5 (RFC2385) was the preferred 3994 method. 3996 Eric Gray's message helps to flesh this out: 3998 The question is not whether MD5 authentication is used, it is how is 3999 it implemented in real BGP implementations or - more importantly - 4000 where is the authentication information located in the packets sent 4001 between two BGP peers? This is not strictly an implementation issue 4002 because authentication information is located in different places 4003 depending on which version of MD5 authentication is in use. 4005 As is generally known, options are not necessarily good. Currently, 4006 between RFC 1771 and RFC 2385, there are two very distinct ways to 4007 accomplish a semantically identical function. If the mechanism 4008 defined in RFC 1771 is not supported by a number of interoperable 4009 implementations, it must be deprecated per RFC 2026 prior to 4010 advancing the specification to Draft Standard. If it is not 4011 implemented and actually in use, it should be deprecated if for no 4012 other reason than to make the 4014 To this Yakov responded: 4016 To be more precise, 4018 In cases in which one or more options or features have not been 4019 demonstrated in at least two interoperable implementations, the 4020 specification may advance to the Draft Standard level only if those 4021 options or features are removed. 4023 So, the relevant question is whether we have at least two 4024 implementations that support authentication as described in rfc1771. 4026 Folks who implemented authentication, as described in rfc1771, please 4027 speak up. 4029 There have been no responses to Yakov's question. 4031 There seems to be a consensus that, since it is little used, and 4032 since there are better mechanisms, namely MD5 authentication, we 4033 should deprecate the BGP Authentication Optional Parameter from 4034 RFC1771. 4036 Ok, after some discussion, this is a list of the text that we are 4037 adding, changing or removing: 4039 1) Remove the reference to the authentication optional parameter: 4041 I would suggest to remove the following text from the draft: 4043 This document defines the following Optional Parameters: 4045 a) Authentication Information (Parameter Type 1): 4047 This optional parameter may be used to authenticate a BGP peer. The 4048 Parameter Value field contains a 1-octet Authentication Code followed 4049 by a variable length Authentication Data. 4051 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | Auth. Code | 4052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 4053 Authentication Data | | | 4054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4056 Authentication Code: 4058 This 1-octet unsigned integer indicates the authentication mechanism 4059 being used. Whenever an authentication mechanism is specified for 4060 use within BGP, three things must be included in the specification: 4062 - the value of the Authentication Code which indicates use of the 4063 mechanism, - the form and meaning of the Authentication Data, and - 4064 the algorithm for computing values of Marker fields. 4066 Note that a separate authentication mechanism may be used in 4067 establishing the transport level connection. 4069 Authentication Data: 4071 Authentication Data is a variable length field that is interpreted 4072 according to the value of the Authentication Code field. 4074 2) Update the introduction: 4076 In section 2 (Introduction), sixth paragraph 4078 From: 4080 BGP runs over a reliable transport protocol. This eliminates the 4081 need to implement explicit update fragmentation, retransmission, 4082 acknowledgment, and sequencing. Any authentication scheme used by 4083 the transport protocol (e.g., RFC2385 [10]) may be used in addition 4084 to BGP's own authentication mechanisms. The error notification 4085 mechanism used in BGP assumes that the transport protocol supports a 4086 "graceful" close, i.e., that all outstanding data will be delivered 4087 before the connection is closed. 4089 To: 4091 BGP uses TCP [RFC793] as its transport protocol. This eliminates the 4092 need to implement explicit update fragmentation, retransmission, 4093 acknowledgment, and sequencing. BGP listens on TCP port 179. Any 4094 authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be 4095 used. The error notification mechanism used in BGP assumes that TCP 4096 supports a "graceful" close, i.e., that all outstanding data will be 4097 delivered before the connection is closed. 4099 3) Update the message header format section: 4101 From: 4103 Marker: 4105 This 16-octet field contains a value that the receiver of the message 4106 can predict. If the Type of the message is OPEN, or if the OPEN 4107 message carries no Authentication Information (as an Optional 4108 Parameter), then the Marker must be all ones. Otherwise, the value 4109 of the marker can be predicted by some a computation specified as 4110 part of the authentication mechanism (which is specified as part of 4111 the Authentication Information) used. The Marker can be used to 4112 detect loss of synchronization between a pair of BGP peers, and to 4113 authenticate incoming BGP messages. 4115 To: 4117 Marker: 4119 This 16-octet field is included for compatibility; it must be set to 4120 all ones. 4122 4) Update the Message Header error handling section: 4124 In section 6.1 (Message Header error handling), second paragraph 4126 From: 4128 The expected value of the Marker field of the message header is all 4129 ones if the message type is OPEN. The expected value of the Marker 4130 field for all other types of BGP messages determined based on the 4131 presence of the Authentication Information Optional Parameter in the 4132 BGP OPEN message and the actual authentication mechanism (if the 4133 Authentication Information in the BGP OPEN message is present). If 4134 the Marker field of the message header is not the expected one, then 4135 a synchronization error has occurred and the Error Subcode is set to 4136 Connection Not Synchronized. 4138 To: 4140 The expected value of the Marker field of the message header is all 4141 ones. If the Marker field of the message header is not as expected, 4142 then a synchronization error has occurred and the Error Subcode is 4143 set to Connection Not Synchronized. 4145 5) Remove a paragraph from the OPEN message error handling section 4146 (section 6.2): 4148 If the OPEN message carries Authentication Information (as an 4149 Optional Parameter), then the corresponding authentication procedure 4150 is invoked. If the authentication procedure (based on Authentication 4151 Code and Authentication Data) fails, then the Error Subcode is set to 4152 Authentication Failure. 4154 6) Update the "Differences from RFC1771 Appendix" 4156 Text not listed here 4158 7) Fix the hole in the numbering by updating: 4160 From: 4162 This document defines the following Optional Parameters: 4164 a) Authentication Information (Parameter Type 1): 4166 To: 4168 This document defines the following Optional Parameters: 4170 a) Optional parameter type 1, Authentication Information, has been 4171 deprecated. 4173 We are at consensus with these changes. 4175 2.63. Clarify MED Removal Text 4177 Status: Consensus 4178 Change: Yes 4179 Summary: Modify text to clear up MED removal behavior. Text is at 4180 the end of the discussion. 4182 Discussion: 4184 This discussion began when Jonathan posted a question to the list: 4186 In reference to: 4188 "A BGP speaker MUST IMPLEMENT a mechanism based on local 4189 configuration which allows the MULTI_EXIT_DISC attribute to be 4190 removed from a route" 4192 Does anybody know how this can be done in IOS??? Looks like it 4193 cannot. 4195 Juniper??? 4197 Other code??? 4199 Change to "SHOULD"??? 4201 Enke responded that: 4203 As the MED value is treated as zero when the MED attribute is 4204 missing, removing the MED attribute is really equivalent to setting 4205 the value to zero. Based on this logic, one can argue that "MED 4206 removal" is supported by multiple vendors. 4208 However, I do see that the current text can be consolidated and 4209 cleaned up: 4211 ------------------------ 4212 5.1.4 MULTI_EXIT_DISC 4214 ... 4216 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4217 which allows the MULTI_EXIT_DISC attribute to be removed from a 4218 route. This MAY be done prior to determining the degree of 4219 preference of the route and performing route selection (decision 4220 process phases 1 and 2). 4222 An implementation MAY also (based on local configuration) alter the 4223 value of the MULTI_EXIT_DISC attribute received over an external 4224 link. If it does so, it shall do so prior to determining the degree 4225 of preference of the route and performing route selection (decision 4226 process phases 1 and 2). 4228 ------------------------- 4230 How about this: 4232 A BGP speaker MUST implement a mechanism based on local configuration 4233 which allows the value of MULTI_EXIT_DISC attribute of a received 4234 route to be altered. This shall be done prior to determining the 4235 degree of preference of the route and performing route selection 4236 (decision process phases 1 and 2). 4238 -------------------------- 4240 In responding to a question, Enke also added: 4242 > Humm. I thought with a missing MED it was preferable to be treated 4243 > as worst not as 0. 4245 It was changed a long time ago. Please see the following text in 4246 Sect. 9.1.2.2 of the draft: 4248 In the pseudo-code above, MED(n) is a function which returns the 4249 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4250 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4251 MULTI_EXIT_DISC value, i.e. 0. 4253 Curtis replied to Enke: 4255 If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a 4256 knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should 4257 change the spec to say that MED(n) returns the largest value possible 4258 is MULTI_EXIT_DISC is missing since this has better loop suppression 4259 behavior if the placement of MULTI_EXIT_DISC removal is moved in its 4260 position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out. In 4261 other words, no matter where the removal takes place, we are loop 4262 free without special rules about comparing EBGP before MED removal 4263 and then IBGP after MED removal. The only argument for MED(n) going 4264 to zero for missing MULTI_EXIT_DISC was that Cisco routers did that 4265 (and change would pose an operational issue if there wasn't a knob to 4266 facilitate the change). 4268 Note that when explicitly jamming a MULTI_EXIT_DISC value, such as 4269 zero, the issue of where in the decision process the MULTI_EXIT_DISC 4270 learned from the EBGP peers could still be used becomes a concern 4271 again. Unfortunately these implementation hints are necessary to 4272 remain loop free and so its hard to declare them out of scope, unless 4273 we forbid changing MULTI_EXIT_DISC and just allow it to be removed 4274 (which does not reflect current practice). 4276 Curtis also added: 4278 The other issue was MED handling. In "5.1.4 MULTI_EXIT_DISC": 4280 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4281 which allows the MULTI_EXIT_DISC attribute to be removed from a 4282 route. This MAY be done prior to determining the degree of 4283 preference of the route and performing route selection (decision 4284 process phases 1 and 2). 4286 An implementation MAY also (based on local configuration) alter the 4287 value of the MULTI_EXIT_DISC attribute received over an external 4288 link. If it does so, it shall do so prior to determining the degree 4289 of preference of the route and performing route selection (decision 4290 process phases 1 and 2). 4292 This doesn't sufficiently address the issue. 4294 The MED step in the decision process is (in 9.1.2.2): 4296 c) Remove from consideration routes with less-preferred 4297 MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable 4298 between routes learned from the same neighboring AS. Routes which do 4299 not have the MULTI_EXIT_DISC attribute are considered to have the 4300 lowest possible MULTI_EXIT_DISC value. 4302 This is also described in the following procedure: 4304 for m = all routes still under consideration 4305 for n = all routes still under consideration 4306 if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) 4307 remove route m from consideration 4309 In the pseudo-code above, MED(n) is a function which returns the 4310 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4311 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4312 MULTI_EXIT_DISC value, i.e. 0. 4314 Similarly, neighborAS(n) is a function which returns the neighbor AS 4315 from which the route was received. 4317 The problem is that a route loop can be formed. 4319 To avoid the route loop, two suggestions were made (2-3 years ago and 4320 nothing was done). One was to make MED(n) return infinity if there 4321 was no MULTI_EXIT_DISC. The other was to consider MULTI_EXIT_DISC in 4322 the decision process only for the purpose of selecting among the EBGP 4323 peers, then remove MULTI_EXIT_DISC, then use that best route in 4324 comparisons to IBGP learned routes. 4326 The statement in 5.1.4 "This MAY be done prior to determining the 4327 degree of preference of the route and performing route selection 4328 (decision process phases 1 and 2)" does not sufficiently address 4329 this. This implies that you MAY also remove after route selection, 4330 in which case field experience indicates you WILL get burned (unless 4331 you know about the caveat above). Initially this came up as an 4332 interoperability issue but later it was proven (in the field) that a 4333 Cisco and another Cisco could form a route loop until Cisco made this 4334 change. 4336 Additional wording is needed either in 5.1.4 or in 9.1.2.2. I 4337 suggest we put a forward reference in 5.1.4: 4339 [...]. This MAY be done prior to determining the degree of 4340 preference of the route and performing route selection (decision 4341 process phases 1 and 2). See section 9.1.2.2 for necessary restricts 4342 on this. 4344 Then in 9.1.2.2 add a clarification to the neighborAS(n) function and 4345 add to the existing text. 4347 Similarly, neighborAS(n) is a function which returns the neighbor AS 4348 from which the route was received. If the route is learned via IBGP, 4349 it is the neighbor AS from which the other IBGP speaker learned the 4350 route, not the internal AS. 4352 If a MULTI_EXIT_DISC attribute is removed before redistributing a 4353 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4354 in the comparison of EBGP learned routes, them removed, then the 4355 remaining EBGP learned route may be compared to the remaining IBGP 4356 learned routes, without considering the MULTI_EXIT_DISC attribute for 4357 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4358 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4359 learned route in the comparison with an IBGP learned route, then 4360 dropping the MULTI_EXIT_DISC and advertising the route has been 4361 proven to cause route loops. 4363 The loop is the classic I prefer your and you prefer mine problem. 4364 It occurs when the router is configured to remove MULTI_EXIT_DISC and 4365 advertise out a route so other routers can use IGP cost to select the 4366 best route. If two routers do this, as soon as they hear the route 4367 with no MULTI_EXIT_DISC from the other peer they start forwarding 4368 toward that peer but they continue to advertise to it since others 4369 IBGP peers are expected to select among the MULTI_EXIT_DISC free IBGP 4370 learned routes using the next step in the decision process, IGP cost. 4372 In this case, what you want is each router to prefer its own EBGP 4373 route, even though it has a MULTI_EXIT_DISC and the IBGP learned 4374 route from the same neighbor AS has had its MULTI_EXIT_DISC stripped 4375 off (or didn't have one, you can't tell which it is). You then want 4376 all of the IBGP peers with a MULTI_EXIT_DISC free route from that AS, 4377 or that have stripped the MULTI_EXIT_DISC to form one, to advertise 4378 them. Others in the AS will then use IGP cost to further resolve 4379 which exit point to use. It make a difference when the route is the 4380 aggregate route of another major provider. IGP cost yields what ISPs 4381 call "hot potatoe routing" and MED selects among multiple heavily 4382 loaded provider interconnects. 4384 [Aside: Having a missing MULTI_EXIT_DISC default to infinity would do 4385 exactly what the ISPs want it to do in the first place and be a lot 4386 easier to explain but we didn't fix that 2-3 years ago when the issue 4387 came up even though we had WG consensus that it was the right thing 4388 to do. The authors didn't act on it at the time (because Cisco 4389 didn't do it that way and the authors preferred to sit on the draft). 4390 At this point we might as well adequately document what we ended up 4391 with.... End of soap box. I don't take myself all that seriously so 4392 others shouldn't either. :-)] 4394 After some more discussion on this, we have this text: 4396 In 5.1.4 replace: 4398 An implementation MAY also (based on local configuration) alter the 4399 value of the MULTI_EXIT_DISC attribute received over EBGP. If it 4400 does so, it shall do so prior to determining the degree of preference 4401 of the route and performing route selection (decision process phases 4402 1 and 2). 4404 with: 4406 An implementation MAY also (based on local configuration) alter the 4407 value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY 4408 be done prior to determining the degree of preference of the route 4409 and performing route selection (decision process phases 1 and 2). 4410 See section 9.1.2.2 for necessary restricts on this. 4412 In 9.1.2.2 replace: 4414 Similarly, neighborAS(n) is a function which returns the neighbor AS 4415 from which the route was received. 4417 with: 4419 Similarly, neighborAS(n) is a function which returns the neighbor AS 4420 from which the route was received. If the route is learned via IBGP, 4421 and the other IBGP speaker didn't originate the route, it is the 4422 neighbor AS from which the other IBGP speaker learned the route. If 4423 the route is learned via IBGP, and the other IBGP speaker originated 4424 the route, it is the local AS. 4426 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 4427 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4428 in the comparison of EBGP learned routes, then removed, then the 4429 remaining EBGP learned route may be compared to the remaining IBGP 4430 learned routes, without considering the MULTI_EXIT_DISC attribute for 4431 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4432 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4433 learned route in the comparison with an IBGP learned route, then 4434 dropping the MULTI_EXIT_DISC and advertising the route has been 4435 proven to cause route loops. 4437 There have been no objections to this, so we are at consensus. 4439 2.64. MED for Originated Routes 4441 Status: Consensus 4442 Change: No 4443 Summary: The consensus is that there is not need to specify default 4444 values for MED in the base draft. 4446 Discussion: 4448 This issue began when it was pointed out that we do not specify the 4449 default values for MED in the base draft. 4451 There were a variety of responses, but the consensus is that since 4452 this is not relevant for interoperability, this does not need to be 4453 in the base spec. 4455 2.65. Rules for Aggregating with MED and NEXT_HOP 4457 Status: Consensus 4458 Change: Yes 4459 Summary: Clear up the text on aggregating with a MED. See the 4460 discussion for the text. 4462 Discussion: 4464 There is a proposal to relax this statement: 4466 "Routes that have the following attributes shall not be aggregated 4467 unless the corresponding attributes of each route are identical: 4468 MULTI_EXIT_DISC, NEXT_HOP." 4470 In his reply to the original mail, Curtis asserted that we should 4471 leave the MED rules alone, but perhaps we could relax the NEXT_HOP 4472 statement. 4474 This was revisited in the "aggregating with MED and NEXT_HOP" thread. 4476 Yakov suggested we replace: 4478 Routes that have the following attributes shall not be aggregated 4479 unless the corresponding attributes of each route are identical: 4480 MULTI_EXIT_DISC, NEXT_HOP. 4482 If the aggregation occurs as part of the update process, routes with 4483 different NEXT_HOP values can be aggregated when announced through an 4484 external BGP session. 4486 Path attributes that have different type codes can not be aggregated 4487 together. Path attributes of the same type code may be aggregated, 4488 according to the following rules: 4490 with: 4492 Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be 4493 aggregated. 4495 Path attributes that have different type codes can not be aggregated 4496 together. Path attributes of the same type code may be aggregated, 4497 according to the following rules: 4499 NEXT_HOP: When aggregating routes that have different NEXT_HOP 4500 attribute, the NEXT_HOP attribute of the aggregated route SHALL 4501 identify an interface on the router that performs the aggregation. 4503 This met with agreement. 4505 Dimitry asked if the "Routes that have different MULTI_EXIT_DESC 4506 attribute SHALL NOT be aggregated." sentence was unnecessary since it 4507 should be a matter of local policy. Jeff replied that it has been 4508 mentioned that removing this stipulation can cause routing loops. 4510 We are at consensus with this issue. 4512 2.66. Complex AS Path Aggregating 4514 Status: Consensus 4515 Change: No 4516 Summary: Since we have two implementations of this method, section 4517 6.8 stays in the specification. 4519 Discussion: 4521 Jonathan opened this discussion with: 4523 The part in the draft about complex AS path aggregation could/should 4524 be deleted. The current draft implies that when aggregating, for 4525 example (1st): 4527 1 2 4 3 4529 w/ 4531 3 4 6 5 4533 and 4535 5 6 7 8 4537 then 4539 1 2 {3 4 5 6} 7 8 4540 ...would be OK 4542 AFAIK, all implementations aggregate by either: (2nd)putting ONLY the 4543 local AS in the path (and setting the atomic) OR (3rd)by creating 1 4544 giant set and adding the local AS as a seq. 4546 So he proposed we remove this to reflect current code. 4548 Jeff replied that there is absolutely nothing wrong with doing 4549 complex aggregation, and there is no reason to remove this from the 4550 specification. 4552 Yakov responded that: 4554 Jonathan is certainly correct that the spec has to reflect current 4555 code. Therefore, unless there are at least two (interoperable) 4556 implementations that implement the algorithm described in "6.8 4557 Complex AS_PATH aggregation", this section has to be removed (this is 4558 irrespective of whether there is something wrong, or nothing wrong 4559 with complex aggregation). With this in mind, if you implement this 4560 algorithm please speak up within a week. If within a week we 4561 wouldn't know that there are at least two implementations the section 4562 will be removed. And likewise, if we hear that there are at least 4563 two implementations, the section will stay. 4565 Jeff replied: 4567 I am also fine with removing it. I just don't think its necessary, 4568 especially if One Of These Days someone decides that running policy 4569 based on as-adjacencies would be a Nice Thing and fixes their 4570 implementation to support "complex" aggregation of paths. 4572 That said, I am aware of no one who implements this. 4574 As an aside, in the thread "last thought on complex aggregation" Jeff 4575 supplied: 4577 I finally remembered what was bothering me about removing complex 4578 aggregation from the spec. 4580 If it is removed, people who do conformance tests and some 4581 implementations may take this to mean "it shall be illegal to have an 4582 AS_PATH that contains a SEQUENCE of a particular type after a SET". 4584 This would make a perfectly ok AS_PATH into one that isn't legal, 4585 even if no implementation currently generates it. 4587 Jonathan replied that he thought the issue was moot since no one has 4588 implemented this. 4590 John replied that, although he is a bit uncomfortable in removing 4591 this from the spec, he doesn't see any harm in doing so. 4593 With this in mind, Yakov suggested we consider the issue closed. 4595 So we will wait a week from 10/17 to see if anyone chimes in. 4597 Siva responded that they have implemented this functionality. So we 4598 need one more...Ben responded that they support this at Marconi as 4599 well. 4601 So we have two implementations, the section stays in the spec. We 4602 are at consensus with this issue. 4604 2.67. Counting AS_SET/AS_CONFED_* 4606 Status: Consensus 4607 Change: Yes 4608 Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to 4609 the BGP Confederations document. Update the base draft to reflect 4610 this by changing section 9.1.2.2. Specific text is at the end of the 4611 discussion. 4613 Discussion: 4615 Jonathan brought up some questions on how current implementations 4616 count AS_SET and AS_CONFED_* 4618 There were a variety of responses to this, answering his questions. 4619 Curtis pointed out that this behavior is covered in: 4621 That's in 9.1.2.2: 4623 a) Remove from consideration all routes which are not tied for having 4624 the smallest number of AS numbers present in their AS_PATH 4625 attributes. Note, that when counting this number, an AS_SET counts 4626 as 1, no matter how many ASs are in the set, and that, if the 4627 implementation supports [13], then AS numbers present in segments of 4628 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4629 count of AS numbers present in the AS_PATH. 4631 Jonathan replied that this might be at odds with what Juniper does, 4632 although he was unsure, and asked for clarification. 4634 This was discussed in the "New Issue AS path" thread. 4636 Yakov proposed that: 4638 The issue of route selection in the present of confederations belongs 4639 *not* to the base spec, but to the spec that describes BGP Confeds. 4640 With this in mind I would suggest to change in 9.1.2.2 from 4642 a) Remove from consideration all routes which are not tied for having 4643 the smallest number of AS numbers present in their AS_PATH 4644 attributes. Note, that when counting this number, an AS_SET counts 4645 as 1, no matter how many ASs are in the set, and that, if the 4646 implementation supports [13], then AS numbers present in segments of 4647 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4648 count of AS numbers present in the AS_PATH. 4650 to 4652 a) Remove from consideration all routes which are not tied for having 4653 the smallest number of AS numbers present in their AS_PATH 4654 attributes. Note, that when counting this number, an AS_SET counts 4655 as 1, no matter how many ASs are in the set. 4657 and ask the authors of BGP Confeds to update their document to cover 4658 how the presence of confeds impact route selection. 4660 This met with agreement, this issue is at consensus. 4662 2.68. Outbound Loop Detection 4664 Status: Consensus 4665 Change: No 4666 Summary: The consensus is, that while this may be a useful technique, 4667 it would break existing methods, and is otherwise out-of-scope for 4668 the base draft. It was suggested that this could be addressed in the 4669 update to RFC1772. 4671 Discussion: 4673 Jonathan brought up that: 4675 This paper (thanks Jeff) http://www.research.microsoft.com/scripts/ 4676 pubs/view.asp?TR_ID=MSR-TR-2000-08 indicates that it is better to do 4677 the loop detection outbound as well inbound. The current draft 4678 indicates that it only needs to be done inbound. IOS does it inbound 4679 as well as outbound. GateD/Juniper does it (did it ???) only 4680 inbound. 4682 So I propose we add: "An implementation MAY choose to not advertise 4683 routes to EBGP peers if these routes contain the AS of that peer in 4684 the AS path." after: "If the autonomous system number appears in the 4685 AS path the route may be stored in the Adj-RIB In, but unless the 4686 router is configured to accept routes with its own AS in the AS path, 4687 the route shall not be passed to the BGP Decision Process." 4689 *If there is at least one other implementation that does outbound 4690 pruning/loop-detection.* 4692 Yakov pointed out that this is ONLY applicable to the base draft if 4693 there are multiple implementations doing this. This issue will only 4694 be considered if these implementors come forward by 10/25/02. 4695 Otherwise the issue will be considered closed. 4697 Jeff replied that there was more at stake with this than if people 4698 had implemented it: 4700 My suggestion is that this can stay out of the base draft. While it 4701 is true that this speeds up convergence (per the paper), it doesn't 4702 affect interoperability. 4704 .in 4 Also, adding this specifically removes the ability from several 4705 implementations to be able to bridge a partitioned AS by permitting 4706 loops. (I'm not going to argue whether this is a Good way to do 4707 this, just that its done.) 4709 Its also worth noting that one could produce the same resultant 4710 speed-up by detecting the loop on an outbound basis and *not* 4711 applying the min*timers to the UPDATE. Thus, this would be a case of 4712 an advertisement of NLRI being treated the same, timer-wise, as the 4713 advertisement of WD_NLRI. 4715 I would suggest moving this suggestion for outbound loop detection in 4716 one form or another to the 1772 replacement. 4718 Yakov agreed with this. 4720 2.69. Appendix A - Other Documents 4722 Over the course of this discussion, a number of issues have been 4723 raised that the group though would be better dealt with in other 4724 documents. These additional documents, and their concomitant issues 4725 will be more fully addressed when the WG turns its focus to them. 4726 These projects are: 4728 1) Update RFC 1772: Application of the Border Gateway Protocol in the 4729 Internet. This will probably entail a complete rewrite. 4731 2) Update Route Reflector (2796) and Confederation (3065) RFC's 4732 regarding their impact on route selection. 4734 3) Write a new document covering BGP Multipath. .ne 4 4736 3. The Issues from -18 to -19 4738 This section lists the issues discussed on the list from November 4739 2002 to late February 2003. 4741 3.1. Reference to RFC 1772 4743 Status: Consensus 4744 Change: No 4745 Summary: Proposed changing RFC 1772 reference, since that document 4746 should be updated. 4748 Discussion: 4750 Jeff proposed that we reconsider referencing RFC 1772, since that 4751 document should be updated. 4753 Yakov pointed out that this is a non-normative reference and can just 4754 be left as is. 4756 Jeff agreed that this wasn't a big deal. We are at consensus to 4757 leave things as they are. 4759 This was discussed in the "-18 last call comments" thread. 4761 3.2. MUST/SHOULD Capitalization 4763 Status: Consensus 4764 Change: Yes 4765 Summary: Capitalize MUST/SHOULD where appropriate. 4767 Discussion: 4769 Jeff brought this up, and Yakov responded asking that he point out 4770 specific instances where this is needed. Jeff said he would do so, 4771 given some time. 4773 Yakov later replied that this would be fixed in the -19 version. 4775 Jeff replied with a master diff showing the MUST/SHOULDs, for the 4776 entire document please see the beginning of the thread entitled: 4777 "Issues list, #2: MUST/SHOULD Capitalization" 4778 This was discussed in the "18 last call comments" thread. This was 4779 also brought up in the "proxy: comments on draft -18" thread. 4781 3.3. Fix Update Error Subcode 7 -- accidently removed 4783 Status: Consensus 4784 Change: Yes 4785 Summary: Add error subcode 7 back in, it looks like it was 4786 inadvertently removed. Add deprecation text to Open Message Error 4787 subcode 5. 4789 Discussion: 4791 Jeff supplied: 4793 Update message error subcode 7 is removed. Especially in -18, it 4794 looks like an editing mistake based on where it would fall in the 4795 editing.. 4797 Yakov mentioned that this is addressed in Appendix A. 4799 Jeff replied: 4801 .in 4 What I would like to see is something like this: 4803 6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 - 4804 Invalid NEXT_HOP Attribute 4806 As it stands, 7 lies on a page boundary and looks like it got clipped 4807 by the roff. 4809 Yakov agreed, and also said he would add similar text for Open 4810 Message Error subcode 5. 4812 This was discussed in the "18 last call comments" thread. 4814 3.4. Section 5.1.4 - Editorial Comment 4816 Status: Consensus 4817 Change: Yes 4818 Summary: Fix "restricts" to "RESTRICTIONS" 4820 Discussion: 4822 Jeff proposed an editorial fix. This is agreed to. 4824 This was discussed in the "-18 last call comments" thread. 4826 3.5. Section 9.1 - Change "all peers" to "peers" 4828 Status: Consensus 4829 Change: Yes 4830 Summary: Section 9.1 - Change "all peers" to "peers" 4832 Discussion: 4834 Jeff proposed: 4836 .in 4 9.1: The output of the Decision Process is the set of routes 4837 that will be advertised to (delete all) peers; the selected routes 4838 will be stored in the local speaker's Adj-RIB-Out according to 4839 policy. 4841 The previous wording implied that routes in the LocRib MUST be placed 4842 in the adj-rib-out. 4844 Yakov agreed, this fix will be in the next revision. 4846 This was discussed in the "-18 last call comments" thread. 4848 3.6. AS Loop Detection & Implicit Withdraws 4850 Status: Consensus 4851 Change: Yes 4852 Summary: Update the text to reflect the AS Loop detection should be 4853 done in the BGP decision process. 4855 Discussion: 4857 John brought this up, and suggested: 4859 .in 4 I have one further comment just in case it's not perfectly 4860 obvious to everyone, which is that "ignore the UPDATE" is not 4861 strictly the action you take when receiving a looped update. Rather, 4862 you treat it as an implicit withdraw, i.e. you process it as any 4863 other update but treat the contained NLRI as unfeasible. 4865 I was going to write that this is sufficiently clear from the spec, 4866 but I regret to say that it isn't. Here is the fourth paragraph of 4867 section 9: 4869 .in 8 The information carried by the AS_PATH attribute is checked for 4870 AS loops. AS loop detection is done by scanning the full AS path (as 4871 specified in the AS_PATH attribute), and checking that the autonomous 4872 system number of the local system does not appear in the AS path. If 4873 the autonomous system number appears in the AS path the route may be 4874 stored in the Adj-RIB-In, but unless the router is configured to 4875 accept routes with its own autonomous system in the AS path, the 4876 route shall not be passed to the BGP Decision Process. Operations of 4877 a router that is configured to accept routes with its own autonomous 4878 system number in the AS path are outside the scope of this document. 4880 .in 4 I don't think this is quite right -- the decision process needs 4881 to be run if the looped routes had previously been advertised 4882 feasibly on the same session. This could be fixed by hacking the 4883 quoted paragraph, but it seems more straightforward to do it by 4884 removing the quoted paragraph and making the fix in 9.1.2 Phase 2 4885 instead. This could be done by inserting the following between the 4886 third and fourth paragraphs of 9.1.2 Phase 2: 4888 .in 8 If the AS_PATH attribute of a BGP route contains an AS loop, 4889 the BGP route should be excluded from the Phase 2 decision function. 4890 AS loop detection is done by scanning the full AS path (as specified 4891 in the AS_PATH attribute), and checking that the autonomous system 4892 number of the local system does not appear in the AS path. 4893 Operations of a router that is configured to accept routes with its 4894 own autonomous system number in the AS path are outside the scope of 4895 this document. 4897 .in 4 Section 9.3, first bullet, also addresses this topic, but I 4898 don't think it's sufficient. 4900 Yakov agreed that this was a change for the better and will include 4901 this in the next revision. 4903 We are at consensus on this issue. 4905 This is discussed in the "-18 last call comments" thread. 4907 3.7. Standardize FSM Timer Descriptions 4909 Status: Consensus 4910 Change: Yes 4911 Summary: Standardize the state descriptions on those listed in the 4912 discussion section of this issue. 4914 Discussion: 4916 Tom proposed: 4918 .in 4 I think a standard description would serve us better instead of 4919 using the following different ways (which I take all to refer to the 4920 same entity): 4922 delayBGP open timer BGP delay open timer BGP open delay timer delay 4923 open timer BGP delay timer 4925 .in 4 I suggest Open Delay timer (with those capitals) 4927 I believe that the corresponding flag is consistently referred to 4928 (apart from the capitalization) as Delay Open flag 4930 Yakov agreed with this suggestion, no one else disagreed, we are at 4931 consensus. 4933 This was discussed in the "BGP18-FSM-terminology" thread. 4935 3.8. FSM MIB enumerations 4937 Status: Consensus 4938 Change: Yes 4939 Summary: Move MIB references from the base spec into the MIB 4940 document. 4942 Discussion: 4944 Tom pointed out that: 4946 The FSM makes several references to putting values into MIB objects 4947 and while some of the values are defined, eg FSM error or Hold Timer 4948 expired, I can find no definition of the following in any of the BGP 4949 documents, MIB or otherwise. 4951 connect retry expired TCP disconnect administrative down collision 4952 detect closure Call Collision cease collision detected and dump 4953 connection Administrative stop 4955 I believe an implementation needs to be told these values somewhere 4956 and that there should be a reference to that place in bgp18. 4958 Jeff replied that to make things easier, the MIB references will be 4959 removed from the base spec, and into the MIB document. 4961 This was discussed in the "WG Last Call FSM MIB enumeration" thread, 4962 and the "bgp18 WG Last Call fsm MIB objects" thread. 4964 3.9. Make "delete routes" language consistent 4966 Status: Consensus 4967 Change: Yes 4968 Summary: Replace a variety of wording with "deletes all routes 4969 associated with this connection,". 4971 Discussion: 4973 Tom pointed out that we use a variety of language to say how we are 4974 going to delete routes in the FSM. He proposed that we instead use: 4976 - deletes all routes associated with this connection, 4978 This met with agreement, and will be reflected in the next version. 4980 This was discussed in the "bgp18 WG Last Call fsm delete action" 4981 thread. 4983 3.10. Correct OpenSent and OpenConfirm delete wording 4985 Status: Consensus 4986 Change: Yes 4987 Summary: Remove delete wording from OpenSent and OpenConfirm states. 4989 Discussion: 4991 Venu asked why there was delete wording in the OpenSent and 4992 OpenConfirm states when a BGP speaker cannot receive routes in these 4993 states. 4995 Jeff acknowledged that this was an error. Yakov agreed to fix the 4996 next version. 4998 This was discussed in the "bgp18 WG Last Call fsm delete action" 4999 thread. 5001 3.11. Incorrect next state when the delay open timer expires 5003 Status: Consensus 5004 Change: Yes 5005 Summary: Fix the next state. 5007 Discussion: 5009 Tom pointed out that: 5011 I believe that there is an incorrect next state when the delay open 5012 timer expires [event 12] in the Active state. The next state should 5013 be OpenSent and not OpenConfirm. 5015 OpenConfirm is for KeepAlive processing when Open messages have been 5016 sent and received. 5018 OpenSent is for Open sent and not yet received. 5020 The corresponding section in Connect state I believe is correct. 5022 Yakov agreed, and will fix this in the next revision. 5024 This was discussed in the "bgp18 WG Last Call fsm incorrect next 5025 state" 5027 3.12. Entering OpenConfirm / Adding "Stop OpenDelay" action 5029 Status: Consensus 5030 Change: Yes 5031 Summary: Add this text: 5033 Change 2 - Connect state event 17 (currently defined as going to 5034 Active) event 9 (stays in Connect state) 5036 new Text: 5038 In response to the connect retry timer expires event [Event 9], the 5039 local system: - drops the TCP connection, - restarts the connect 5040 retry timer, - stops the Open Delay timer and resets the timer to 5041 zero, - initiates a TCP connection to the other BGP peer, - continues 5042 to listen for a connection that may be initiated by the remote BGP 5043 peer, and - stays in Connect state. 5045 If the TCP connection fails [Event17], the local system: - restarts 5046 the connect retry timer, - stops the Open Delay timer and resets 5047 value to zero, - continues to listen for a connection that may be 5048 initiated by the remote BGP peer, and - changes its state to Active. 5050 Further discussion on Keepalives has been moved to issue 52. 5052 Discussion: 5054 This discussion began with Tom outlining these two points: 5056 When the OpenConfirm state is entered from OpenSent with the receipt 5057 of a valid open [Event 18], then a KeepAlive message is sent and the 5058 timer is started. 5060 When the OpenConfirm state is entered from Active or Connect on 5061 receipt of a valid open [Event 19], no message is sent, no timer is 5062 started. I believe this inconsistency is an error and should be 5063 corrected by adding these two actions in those two places. 5065 Sue replied: 5067 Just to clarify this comment: Event 19 = valid open with delay timer 5068 running 5070 Active = 1) awaiting TCP connection, or 2) TCP connection completed 5071 and awaiting the TCP connection with delay timer running 5073 Case 1: - should not see Event 19 In transition from Active to Open 5074 Confirm, the connection must have a TCP connection completed. Case 1 5075 does not have this occurring, so the transition must be avoided. 5077 Case 2: - should see Event 19 5079 - Open, Keepalive should be sent. 5081 Previous text: (Action H from FSM document) 5083 If an Open is received with the BGP Delay Open timer running, [Event 5084 19], the local system: - clears the connect retry timer [cleared to 5085 zero), - completes the BGP initialization, - stop and clears the BGP 5086 Open Delay timer, - Sends an Open Message, - sets the hold timer to a 5087 large value (4 minutes), and - changes its state to an Open Confirm. 5089 New text: [a New Action - N-2 : N + BGP keepalive sent] 5091 If an Open is received with the BGP Delay Open Timer running [Event 5092 19], the local system: - clear the connect retry timer [cleared to 5093 zero], - completes the BGP initialization, - stops and clears the BGP 5094 Open Delay timer, - Send an Open message, - Sends a Keepalive 5095 message, - If hold timer value is non-zero, - set keepalive timer - 5096 hold timer reset to negotiated value else if hold timer is zero, - 5097 reset the keepalive timer, and - reset the hold timer. 5099 - If the value of the autonomous system field is the same as the 5100 local Autonomous system number, set the connection status to a 5101 internal connection; otherwise it is "external". 5103 Tom and Sue discussed the OpenDelay state, and recalled that this was 5104 excluded a number of months ago as not reflecting current practice. 5106 By way of clarification, Sue added: 5108 1) Agree, this can occur in the Active state as well as the Connect 5109 state. Will you accept the earlier text below to be inserted both 5110 places? 5112 Background: 5114 The state machine for Event 19 is: 5116 Idle Connect Active Open Open Estb Sent Confirm 5117 ================================================ Event 19 | | | | | | 5118 | next state |Idle | Open | Open | Open |Idle | Idle | | | confirm| 5119 confirm| Confirm| | | 5120 ================================================ action | V | N-2 | 5121 N-2 | N | E-1 | E | ================================================ 5123 Per the State Machine. 5125 Action v - FSM Error Action E - FSM Error, drop connection - etc, 5126 drop routes Action E-1 - FSM Error, drop connection (lots of Action 5127 N-2 (text below) Action N (text below, without sending Open) 5129 2) Do you think that Event 19 is possible in the Open Sent state? 5131 Please answer this separately. 5133 Tom replied that: 5135 .in 4 1) yes I think the same text in both Active and Connect states 5136 is a good resolution 5138 2) complicated. As the fsm text stands, Event 19, along with a host 5139 of others, takes us back from Open Sent to Idle (I assume on the 5140 grounds this is an error condition) which seems very reasonable. 5142 But ...in quite a few places, such as Connect state events 2, 5143 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer 5144 when going to Idle or Active so we could then go from eg Idle with 5145 Manual start [event 1] to Connect to Open Sent all before the 5146 OpenDelay timer expires in which case event 19 can occur validly in 5147 Open Sent - obscure but possible. (This is also true with Active 5148 state and events 2, 17 and the default list at the end). 5150 But I think this is an error, and that when exiting Connect state or 5151 Active state as listed above, we should have an additional action to 5152 stop the OpenDelay timer in which case event 19 in Open Sent becomes 5153 an error condition (again). 5155 But but but as ever, I cannot speak with authority for 5156 implementations and so if implementations do not stop the OpenDelay 5157 timer when exiting as above, then Event 19 is valid in Open Sent 5158 state - obscure but possible (again). 5160 My wish is to add the extra action, stop OpenDelay timer, for the 5161 events listed above in Active and Connect states in the expectation 5162 that that is what people have or should have implemented. 5164 Tom added a response to Sue after some other threads have been 5165 discussed: .in 4 5167 You asked if event 19 (Open with OpenDelay timer running) was 5168 possible in OpenSent state; I gave a lengthy reply (below) to the 5169 effect yes it could because the OpenDelay timer did not always get 5170 stopped but the timer should be stopped in which case the event would 5171 not happen. 5173 Reading your responses to Siva , I see you include stopping the Open 5174 Delay timer in the action 'release all BGP resources' when going to 5175 Idle (which I missed seeing earlier in the year). 5177 That eliminates most but not all of the possibilities I mentioned. I 5178 now believe we would need to add the action 'stop OpenDelay timer' 5179 for Connect state event 17 (currently defined as going to Active) 5180 event 9 (stays in Connect state) 5182 in order to stop event 19 in Open Sent 5184 Sue replied that, she thought this was at consensus, and provided the 5185 new text, which is: 5187 Change 1: new text 5189 Active state - event 19 5191 If an Open is received with the Open Delay timer is running [Event 5192 19], the local system - clears the connect retry timer (cleared to 5193 zero), - stops and clears the Open Delay timer - completes the BGP 5194 initialization, - stops and clears the Open Delay timer - sends an 5195 OPEN message, - send a Keepalive message, - if the hold timer value 5196 is non-zero, - starts the keepalive timer to initial value, - resets 5197 the hold timer to the negotiated value, else if the hold timer is 5198 zero - resets the keepalive timer (set to zero), - resets the hold 5199 timer to zero. 5201 - changes its state to OpenConfirm. 5203 If the value of the autonomous system field is the same as the local 5204 Autonomous System number, set the connection status to an internal 5205 connection; otherwise it is "external". Change 2 - Connect state 5206 event 17 (currently defined as going to Active) event 9 (stays in 5207 Connect state) 5209 new Text: 5211 In response to the connect retry timer expires event [Event 9], the 5212 local system: - drops the TCP connection, - restarts the connect 5213 retry timer, - stops the Open Delay timer and resets the timer to 5214 zero, - initiates a TCP connection to the other BGP peer, - continues 5215 to listen for a connection that may be initiated by the remote BGP 5216 peer, and - stays in Connect state. If the TCP connection fails 5217 [Event17], the local system: - restarts the connect retry timer, - 5218 stops the Open Delay timer and resets value to zero, - continues to 5219 listen for a connection that may be initiated by the remote BGP peer, 5220 and - changes its state to Active. 5222 Tom replied that: 5224 .in 4 Change 2, stop Open Delay timer in Connect state events 9 and 5225 17, fine; that is what I understand to be the real issue 12. 5227 Change 1, event 19 in Active state, is IMHO issues 47 and 52. This 5228 is tangled because the initial paragraphs of Issue 12 in the issue 5229 list are nothing to to with stopping Open Delay timer and everything 5230 to to with sending a Keepalive message before entering Open Confirm 5231 state from Active or Connect state on event 19; which I raised and 5232 see as issue 52. Issue 47 was Siva's issue 28 and relates to a 5233 different action for Active state event 19. 5235 I agree with change 1 in that it adds in the sending of Keepalive 5236 which I believe essential; I think Siva needs to respond concerning 5237 issue 47. (nb the stop Open Delay action is duplicated) I wonder if 5238 we should use a different character for the bullet points under the 5239 if and else clauses to make it clear where they end ie - if the hold 5240 timer .... + do this + and this else if ... + do the other + and this 5242 But I still have an issue for Connect state event 19 where I believe, 5243 as for Active state event 19, we should send a Keepalive and start 5244 the Keepalive timer. I will pursue this as part of issue 52 if that 5245 suits you. I think the text will be the same as whatever we agree 5246 for Active state event 19. 5248 This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" 5249 thread. And also in the "Event 19 in Open Sent state was Re: bgp18 5250 WG Last Call fsm missing keepalive" thread. This also came up in the 5251 "issues 12 - consensus & two changes - 2nd message" thread. 5253 3.13. FSM Missing Next States 5255 Status: Consensus 5256 Change: Yes 5257 Summary: Seven sub-issues spawned to resolve each of the next-state 5258 questions. See each sub-issue for specifics. 5260 Discussion: 5262 This began with Tom pointing out 7 places where the next state was 5263 not clear. Interlaced with his comments below is the proposed text 5264 to fix the problems and the status of the issue. 5266 All sub-issues are at consensus. 5268 This conversation was started in the "bgp18 WG Last Call fsm missing 5269 next state" thread. 5271 3.13.1. FSM Missing Next States - Event 15 or 16 (Connect State) 5273 Status: Consensus 5274 Change: Yes 5275 Summary: Add next state of Connect. 5277 Discussion: 5279 Tom pointed out that: 5281 Connect State: 5283 If the TCP connection succeeds [Event 15 or Event 16], the local 5284 system checks the "Delay Open Flag". If the delay Open flag is set, 5285 the local system: **enters what state 5287 Sue proposed these changes: 5289 1) Connect State - Event 15 or Event 16 [consensus, editorial] 5291 note: The delay retry timer is utilized instead of the connect retry 5292 timer for the next two changes. Previous text: 5294 If the TCP connection succeeds [Event 15 or Event 16], local system 5295 checks the "Delay Open Flag". If the delay open flag is set, the 5296 local system: - clears the connect retry timer, - sets the BGP open 5297 delay timer to initial value If the Delay Open flag is not set, the 5298 local system: - clears the connect retry timer, - clear BGP Open 5299 Delay timer (set to zero), - completes the BGP initialization, - send 5300 an Open message to its peer, - sets hold timer to a large value, and 5301 - change the state to Open Sent. 5303 New text: 5305 If the TCP connection succeeds [Event 15 or Event 16], local system 5306 checks the Delay Open flag prior to processing: If the Delay Open 5307 flag is set, the local system: - clears the connect retry timer, - 5308 sets the BGP open delay timer to initial value, and - stays in the 5309 Connect state. 5311 If the Delay Open flag is not set, the local system: - clears the 5312 connect retry timer, - clears the BGP Delay timer (sets to zero), - 5313 completes the BGP initialization, - sends an Open message to its 5314 peer, - sets the hold timer to a large value, and - changes the state 5315 to Open Sent. 5317 Tom agreed that this was good, with the change to "Open Delay timer" 5318 as discussed in issue 7. 5320 This conversation was started in the "bgp18 WG Last Call fsm missing 5321 next state" thread. 5323 3.13.2. FSM Missing Next States - Event 14 (Connect State) 5325 Status: Consensus 5326 Change: Yes 5327 Summary: We selected option 2 from discussion as the correct text: 5329 2) treat it as an invalid response, reject the connection and see if 5330 a valid configured one comes within the connect timer's window. 5332 Discussion: 5334 Tom pointed out that: 5336 Connect State: 5338 If the TCP connection receives an indication that is invalid or 5339 unconfigured. [Event 14]: **enters what state 5341 Sue proposed these alternatives: 5343 2)Connect State - Event 14 [no consensus] 5345 Current Text: If the TCP connection receives an indication that that 5346 is invalid or unconfigured [Event 14], - the TCP connection is 5347 rejected. At the very least this section needs more "word smithing", 5348 so I'd like to change it for more clarity at least. 5350 I'm not sure this represents the implementations. What I'd like to 5351 do is query the implementations to see what they do if they receive a 5352 valid TCP connection with an invalid or unconfigured peer. Two 5353 options: Alternative 1: Count it as a valid response New Text: If a 5354 TCP connection is received that has an invalid format, or an 5355 unconfigured host [Event 14], the local system: - rejects the TCP 5356 connection, - increments the connect retry counter, - performs bgp 5357 peer oscillation checks. If bgp peer oscillation checks allow for a 5358 new connection, the bgp peer - restarts the Connect retry timer with 5359 configured value, and - enters the Active state. FSM table: Idle 5360 Connect Active Open-Sent Open-Confirm Establish Event-14 5361 ======================================================= Next state 5362 Idle | Active|Active|Open-Sent|Open-Confirm|Establish| 5363 ======================================================= action V | Y2 5364 | L | Ignore | Ignore | Ignore | 5365 ======================================================= Alternative 5366 2: Reject the connection and see if valid or configured one appears 5367 within the connect timer window. 5369 New Text: If a TCP connection is received that has an invalid format, 5370 or an unconfigured host [Event 14], the local system: - rejects the 5371 TCP connection, - and stays in the Connect state. 5373 FSM table: Idle Connect Active Open-Sent Open-Confirm Establish 5374 Event-14 ======================================================= Nxt 5375 state Idle |Connect|Active|Open-Sent|Open-Confirm|Establish| 5376 ======================================================= action V | L 5377 | L | Ignore | Ignore | Ignore | 5378 ======================================================= 5380 Sue then sent out a call to implementors to let the list know what 5381 they did with their FSMs. Tom replied that he agreed that we need to 5382 wait to see what the existing implementations do. He also suggested: 5384 **tp need a then clause here 'if bgp peer oscillation damping does 5385 not allow for a new connection, then the local system ???' 5387 be added before the FSM table in option 1 of the proposed text. 5389 Sue prodded the list saying that: 5391 Should the peer: 1) Treat it as a valid response, and enters the 5392 active state to watch for a another TCP connection with a valid peer. 5394 2) treat it as an invalid response, reject the connection and see if 5395 a valid configured one comes within the connect timer's window. 5397 Without further input, I will select option 2. 5399 Curtis replied that this was fine with him. 5401 There has been no further disagreement, we are at consensus on this. 5403 This conversation was started in the "bgp18 WG Last Call fsm missing 5404 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5405 input needed from developers" thread. 5407 3.13.3. FSM Missing Next States - Event 15 or 16 (Active State) 5409 Status: Consensus 5410 Change: Yes 5411 Summary: Add text listed in discussion. 5413 Discussion: 5415 Tom pointed out: 5417 Active State: 5419 A TCP connection succeeds [Event 15 or Event 16], the local system: 5420 process the TCP connection flags - If the BGP delay open flag is set: 5421 ** enters what state (I think this is an FSM error in TCP because it 5422 has not initiated a connection!) 5424 Sue proposed these changes: 5426 Previous text: A TCP connection succeeds [Event 15 or Event 16], the 5427 local system: process the TCP connection flags - If the BGP delay 5428 open flag is set: - clears the connect retry timer [through the 5429 following text: - and changes its state to Open Sent. 5431 New text: If the TCP connection succeeds [Event 15 or Event 16], 5432 local system checks the "Delay Open Flag" prior to processing: If the 5433 delay open flag is set, the local system: - clears the connect retry 5434 timer, - sets the BGP open delay timer to initial value, and - stays 5435 in the Active state. 5437 If the Delay Open flag is not set, the local system: - clears the 5438 connect retry timer, - clears the BGP Delay timer (sets to zero), - 5439 completes the BGP initialization, - sends an Open message to its 5440 peer, - sets the hold timer to a large value, and - changes the state 5441 to Open Sent. 5443 Tom agreed with this. 5445 This conversation was started in the "bgp18 WG Last Call fsm missing 5446 next state" thread. 5448 3.13.4. FSM Missing Next States - Event 13-17 (TCP Connection) 5450 Status: Consensus 5451 Change: Yes 5452 Summary: We selected: 5454 Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 be 5455 mandatory. 5457 Discussion: 5459 Tom started this by saying that: 5461 If the local system receives a valid TCP Indication [Event 13], the 5462 local system processes the TCP connection flags. ** enters what state 5464 If the local system receives a TCP indication that is invalid for 5465 this connection [Event 14]: ** enters what state 5467 Sue proposed we move this to the "fsm missing next state - Events 5468 13-17 and the TCP connection" thread. 5470 The response in this thread was: 5472 4) Active State, Event 13 [no consensus] 5) Active State, Event 14 5473 [no consensus] 5475 The problem with this state is it is difficult to exactly specify 5476 without discussing the TCP Messages that FSM document covers. I'll 5477 query if the implementors require all of events 13-17 as mandatory. 5479 Sue polled the implementors on the list with this query: 5481 These events are described in section 8.1.3. 5483 In our discussion in January through May of 2002, many implementers 5484 mapped their implementation onto the following TCP events list in 5485 8.1.3. 5487 Events 13 - 17 5489 Event 13 - TCP connection indication & valid remote peer 5491 Event 14 - TCP connection indication with invalid source or 5492 destination Event 15 - TCP connection request sent (by this peer) 5493 received an Acknowledgement 5495 [ local system sent a TCP SYN, Received a TCP SYN, ACK pair back, and 5496 Sent a TCP ACK] 5498 Event 16 - TCP connection confirmed 5500 [local system received a TCP SYN, sent a TCP SYN, ACK back, and 5501 received a TCP ACK] 5503 Event 17 - TCP connections 5505 Should we have all of these states? Which implementations support 5506 all of these Events? 5508 The full FSM text was snipped here for brevity. 5510 Sue prodded the list with: 5512 Do the implementors require Events 13 - 17 in the State machine ? 5514 Event 13 - TCP connection valid indication Event 14 - TCP connection 5515 invalid indication Event 15 - TCP connection request acknowledged 5516 Event 16 - TCP connection confirmed Event 17 - TCP connection fails 5518 Choice 1: Events 13 - 17 are mandatory Choice 2: Event 13 and Event 5519 14 be optional, and Events 15 - 17 be mandatory. If no one objects, 5520 we will use Choice 2. 5522 Curtis said this was fine with him. 5524 There has been no further disagreement, we are at consensus on this. 5525 This was started in the "bgp18 WG Last Call fsm missing next state" 5526 thread. And continued in the "fsm missing next state - Events 13-17 5527 and the TCP connection" thread. It was also discussed in the "BGP 5528 draft-19 - FSM input needed from developers" thread. 5530 3.13.5. FSM Missing Next States - Event 17 (Connect State) 5532 Status: Consensus 5533 Change: No 5534 Summary: Closed in favor of 13.4 5536 Discussion: 5538 If the local system receives a TCP connection failed [Event 17] 5539 (timeout or receives connection disconnect), the local system will: 5540 ** enters what state 5542 Sue replied with this: 5544 .in 4 comment: In the Active state, we may already have a connection 5545 and be awaiting the Open Delay timer. The TCP disconnect or timeout 5546 could occur in this state due to the "Open Delay Timer". If the TCP 5547 Disconnect is ignored, we could have some peer oscillation. 5549 If the we wait, then the connection retry timer needs to be kept 5550 running. The text below allows this timer. The real question is 5551 what is the status of the current implementations. 5553 I agree, the Active state and the connect state should match. 5555 Old Text: If the TCP connection fails (timeout or disconnection) 5556 [Event 17], the local system: - set TCP disconnect in the MIB reason 5557 code, - restart Connect retry timer (with initial value), - release 5558 all BGP resources, - Acknowledge the Drop of the TCP connection if 5559 TCP disconnect (FIN ACK), - Increment ConnectRetryCnt (connect retry 5560 count) by 1, and - performs the BGP peer oscillation damping process. 5562 Applicable FSM State table: FSM table old: Event 17 current: Idle 5563 Connect Active Open-Sent Open-Confirm Establish 5564 ========================================================= Next state 5565 Idle |Active |Idle |Active | Idle |Idle | | | | | | | 5566 ========================================================= action V | 5567 Y2 | G | Ignore| Track 2nd | Track 2nd | | | | | connection | 5568 connection| ========================================================= 5570 Alternative 1: 5572 FSM table new: 5574 Event 17 current: Idle Connect Active Open-Sent Open-Confirm 5575 Establish ========================================================= 5576 Next state Idle |Active |Active |Active | Idle |Idle | | | | | | | 5577 ========================================================= action V | 5578 G | G | Ignore| Track 2nd | Track 2nd | | | | | connection | 5579 connection| ========================================================= 5580 G: The local system: - restarts the connect retry timer (at initial 5581 value), - continues to listen for a connection that may be initiated 5582 by the remote peer, and - sets its next state to Active. 5584 New Text: (for Connect and Active state) If the TCP connection fails 5585 (timeout or disconnect) [Event 17], the local system: - restarts the 5586 connect retry timer, - continues to listen for a connection that may 5587 be initiated by the remote BGP peer, and - changes it state to 5588 Active. Alternative 2: FSM table new: Event 17 current: Idle Connect 5589 Active Open-Sent Open-Confirm Establish 5590 ========================================================= Next state 5591 Idle |Idle |Idle |Active | Idle |Idle | | | | | | | 5592 ========================================================= action V | 5593 Y2 | Y2 | Ignore| Track 2nd | Track 2nd | | | | | connection | 5594 connection| ========================================================= 5595 Next Text: If the location system receives a TCP connection failed 5596 [Event 17], the local system will: - increment the ConnectRetryCnt 5597 (connect retry count) by 1, - release all BGP resources associated 5598 with this connection, - perform BGP peer oscillation (if configured), 5599 and - go to Idle 5601 Y2 - is: The local system: 1) increments the ConnectRetryCnt (connect 5602 retry count) by 1, 2) releases all BGP resources associated with this 5603 connection, and 3) performs the BGP peer oscillation damping process 5605 if the damping process allows for a new connection, the local system: 5606 - restarts the connect retry timer (with initial value, and - goes to 5607 Idle If the damping process does not allow for a new connection, the 5608 local system - set the flags to damp the creation of a new bgp 5609 connection until a manual start occurs, and - goes to Idle. 5611 Tom agreed with the options, and stated that he preferred option 2. 5612 Sue is also happy with option 2, if no one else chimes in. 5614 After the issues list came out Tom responded to this issue, saying: 5616 .in 4 I think this issue SHOULD be administratively terminated. 5618 It relates to Connect state Event 17 (TCP connection fails) and I am 5619 credited with raising it; in fact, the issue I raised was missing 5620 next state for Active state event 17 and this has now been subsumed 5621 into 13.4 (but note that 13.4 does not explicitly say Active state - 5622 I know it should because I raised that issue too). I will ensure it 5623 does not get lost from any resolution of 13.4. 5625 And Connect state event 17 does appear as part of issue 45 which Siva 5626 raised so I think that either way, 13.5 can go. 5628 This conversation was started in the "bgp18 WG Last Call fsm missing 5629 next state" thread. 5631 3.13.6. FSM Missing Next States - Event 18 (Open Confirm) 5633 Status: Consensus 5634 Change: Yes 5635 Summary: This is the text: 5637 .in 4 In the Open Confirm state, a valid Open message [Event 22] is 5638 received. The BGP Peer connection is check to see if there is a 5639 collision per section 6.8. If this connection is to be dropped due 5640 to the call collision, the local system will drop the call by: 5642 - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to 5643 zero), - releases all BGP resources (this includes stopping the Open 5644 Delay Timer and reseting it to zero), - increments the 5645 ConnectRetryCnt by 1 (connect retry +count), and - optionally 5646 performs a BGP peer oscillation damping processing, and - enters the 5647 Idle State. 5649 Discussion: Tom opened this with: 5651 Open Confirm State: 5653 If the Open messages is valid [Event 18], the collision detect 5654 function is processed per section 6.8. If this connection is to be 5655 dropped due to call collision, the local system: ** enters what state 5657 Sue replied with: 5659 Here's my proposed text. Please let me know what you think. I think 5660 this is an editorial change. Old text: If the open message is valid, 5661 the collision detect function is processed per section 6.8. If this 5662 connection is to be dropped due to call collision, the local system: 5663 - sends a Notification with a Cease - resets the Connect timer (to 5664 zero), - releases all BGP resources, - Drop the TCP connection (sends 5665 a TCP FIN), - increments the ConnectRetryCnt by 1 (connect retry 5666 count), and - performs an BGP peer oscillation damping process. 5668 New text: If the open message is valid, the BGP peer connection is 5669 check to detect a collision per section 6.8. If this connection is 5670 to be dropped due to call collision, the local system: - sends a 5671 Notification with a Cease - resets the Connect timer (to zero), - 5672 releases all BGP resources, - Drop the TCP connection (sends a TCP 5673 FIN), - increments the ConnectRetryCnt by 1 (connect retry count), 5674 and - performs an BGP peer oscillation damping processing, and - 5675 enters the Idle State. notes: Collision detect impacts Open Sent, 5676 Open Confirm, and Established states. 5678 Tom replied: 5680 .in 4 I am still struggling with; we are in OpenConfirm so we already 5681 have received an Open from the remote peer and Event 18 is a second 5682 Open from the same peer. Perhaps my struggle is that I think in 5683 terms of two (or more) FSM for a given IP address pair so the Open 5684 Collision detection will occur when the/an- other FSM receives a 5685 valid Open in states Active/Connect/Open Sent and will generate Event 5686 22 into this FSM so Event 18 cannot occur. But yes, if Event 18 can 5687 occur in this FSM and this connection is to be dumped, then Idle 5688 state it should be as you suggest. I have slotted in [optionally] in 5689 front of the peer oscillation damping in your text because I think it 5690 should be optional:-) 5692 Sue replied: 5694 this mechanism allows a single fsm to handle both. 2 fsm and 1 fsm 5695 BGP FSM seem to exist. (I queried implementors a few times on this 5696 one. So, I just put in this change to provide the flexibility. 5698 Collision detect tends to give scrambled brains for most people.. As 5699 Dennis Ferguson said 2 years ago, that's the hardest part of the FSM. 5701 Sue then stated that she would query implementors to see what is 5702 being done. 5704 Sue prodded the list with: 5706 .in 4 In the Open Confirm state, a valid Open message [Event 22] is 5707 received. The BGP Peer connection is check to see if there is a 5708 collision per section 6.8. If this connection is to be dropped due 5709 to the call collision, the local system will drop the call by: 5711 - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to 5712 zero), - releases all BGP resources (this includes stopping the Open 5713 Delay Timer and reseting it to zero), - increments the 5714 ConnectRetryCnt by 1 (connect retry +count), and - optionally 5715 performs a BGP peer oscillation damping processing, and - enters the 5716 Idle State. 5718 Implementors need to verify if this text and the text for Event 22 5719 allows all implementors to perform the necessary Call Collision 5720 actions. If no objects, we will use this text. 5722 Curtis said he had no problem with this. 5724 There has been no disagreement, we are at consensus with this. 5726 This conversation was started in the "bgp18 WG Last Call fsm missing 5727 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5728 input needed from developers" thread. 5730 3.14. FSM - Peer Oscillation Damping 5732 Status: Consensus 5733 Change: Yes 5734 Summary: Change references to peer oscillation damping to consistent 5735 phrase: 5736 "[optionally] performs peer oscillation damping". Also remove old 5737 reference to "BGP Peer Restart Backoff Mechanisms". 5739 Discussion: 5741 Tom suggested we use consistent terminology to refer to peer 5742 oscillation damping. He also pointed out a stale reference. 5744 Yakov agreed to fix both of these. 5746 3.15. FSM - Consistent FSM Event Names 5748 Status: Consensus 5749 Change: Yes 5750 Summary: Make FSM names consistent. Specifics are in the discussion 5751 section. 5753 Discussion: 5755 Tom proposed that: 5757 .in 4 The event name used in the FSM show much variation to the point 5758 sometimes where I am not clear that it is always the same event (eg 5759 where the event name is qualified by a subset of the possible 5760 causes). Assuming that it is, I propose the following changes to 5761 make the wording consistent, clear and concise for event names. 5763 ** denotes changed text using the convention /'old text'/'new text'/ 5765 8. BGP Finite State machine 5767 Event1: Manual start Event2: Manual stop Event3: Automatic start 5768 **Event4: Manual start with passive TCP /establishment/flag/ 5769 **Event5: Automatic start with passive TCP /establishment/flag/ 5770 Event6: Automatic start with bgp_stop_flap option set **Event7: 5771 Auto//matic/ stop Event8: Idle hold timer expires Event9: Connect 5772 retry timer expires **Event10: Hold time//r/ expires Event11: 5773 Keepalive timer expires Event12: Open Delay timer expires **Event13: 5774 TCP connection valid indication **Event14: TCP connection invalid 5775 indication **Event15: TCP connection request /sent received an ACK/ 5776 acknowledged/ Event16: TCP connection confirmed Event17: TCP 5777 connection fails Event18: BGPOpen Event19: BGPOpen with *Open Delay 5778 timer running Event20: BGPHeaderErr Event21: BGPOpenMsgErr Event22: 5779 Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg 5780 Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr 5782 8.2.2 Finite State Machine 5784 Connect State: 5786 If the BGP port receives a ** valid TCP connection indication [Event 5787 13], 5789 If the TCP connection receives **an invalid indication [Event 14]: 5791 If the TCP connection fails **/(timeout or disconnect)// [Event17] 5793 Active State: 5795 If the local system receives a **valid TCP //indication/ [Event 13], 5796 If the local system receives a TCP connection failed [Event 17] 5797 **/(timeout or receives connection disconnect)//, 5799 Open Sent: If a connection in Open Sent is determined to be the 5800 connection that must be closed, an **/administrative collision 5801 detect/Open collision dump/ [Event 22] is signaled to the state 5802 machine. If such an **/administrative collision detect dump [Event 5803 22]/event/ is If a TCP **//connection valid/ indication [Event 13] or 5804 TCP **//connection/ request **//acknowledged/ [Event 15] Open Confirm 5805 State: ...or receives a TCP **/Disconnect// connection fails/ [Event 5806 17] from the 5808 In the event of **/TCP establishment//TCP connection valid indication 5809 /[Event 13] 5811 ...the local system will **/issue a call/generate an Open/ collision 5812 dump [Event 22]. When the local system receives a **/call/open/ 5813 collision dump event [Event 22]/such an event/, the 5815 Established State: **/disconnect from the underlying TCP/TCP 5816 connection fails/ [Event17], it: 5818 ... it will process **/a Call/an Open/ Collision dump event[Event 5819 22]. 5821 Notes: Event 4 title brought in line with text Event 5 title brought 5822 in line with text Event 7 title brought in line with text Event 13 5823 title shortened to be closer to text, text brought in line Event 14 5824 title shortened to be closer to text, text brought in line Event 15 5825 title brought in line with text Event 17 text brought in line with 5826 title (text often introduces qualifying conditions that are too 5827 restrictive) Event 22 text brought in line with title 5829 Sue replied: 5831 I will accept the text you proposed for the Event names. I will 5832 update the FSM text to include your changes. We'll consider issue 15 5833 in consensus. I've fixed the text. 5835 So we are at consensus here. 5837 This is discussed in the thread: "bgp18 WG Last Call fsm event 5838 names." It was also discussed in the "Issue 15 - Consistent FSM 5839 Event Names" thread. 5841 3.16. Many Editorial Comments 5843 Status: Consensus 5844 Change: Yes 5845 Summary: Many editorial suggestions, and what we are doing with them 5846 are listed below. Some issues have been broken out separately where 5847 there is a longer discussion on them. 5849 Discussion: 5851 Alex began this by presenting comments from an anonymous reviewer, 5852 unless otherwise noted, responses are from Yakov: 5854 > Almost all of these are simple clarifications. > > Section 1, page 5855 5: IGP definition - it's not clear from this > definition whether 5856 IBGP would be considered an IGP? any suggestion on how to improve the 5857 definition to clarify this issue would be appreciated. 5859 There was some further discussion on this and it was decided that 5860 people reading this document ought to know what an IGP is. 5862 > Section 3, page 7, para 4: Does RFC 1772 still represent the > 5863 *planned* use of BGP? Or the actual use? Or something > different 5864 from actual use? 5866 Perhaps we should just take out references to 1772. 5868 Further discussion seemed to indicate that this reference should 5869 stay. 5871 > Section 3, page 8, para 3 - "The hosts executing..." This > 5872 paragraph seems obsolete. 5874 I'll take it out. 5876 With regard to this, Siva asked if some route optimization vendors 5877 rely on this. Since this wasn't resolved, it is discussed further in 5878 issue 17. 5880 > Section 4.1, page 11 - Length is in network byte order. 5882 all the encodings are in network byte order. This applies not just 5883 to the BGP spec, but to other protocols as well. 5885 This comment was made about a number of fields. It was later agreed 5886 that a reference would be made to this at the beginning of the 5887 document. 5889 > Section 4.2, page 12 - Hold Time - what does a value of zero > 5890 indicate? 5892 if you read section 4.4 then you'll find that: If the negotiated Hold 5893 Time interval is zero, then periodic KEEPALIVE messages MUST NOT be 5894 sent. 5896 > Section 4.2, page 13 - BGP Identifier - network byte order? > "IP 5897 address" -> "IPv4 address" 5899 I'll put at the beginning a sentence saying that in the context of 5900 this document the term "IP address" means an IP Version 4 address. 5902 > Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> > 5903 "path attributes" 5905 fixed. 5907 > Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address" > 5908 Specify that this is 4 octets. > Reference here to multi-protocol 5909 extensions for IPv6 > nexthop? 5911 no. 5913 > RFC 2283 is unclear whether NEXT_HOP should always be > included 5914 when using multiprotocol extensions. Clarify > this here? 5916 It is already clarified in 2283bis. 5918 > Section 4.3, Page 17/18 - MED and LocalPref: > "non-negative" -> 5919 "unsigned" for consistency with > elsewhere. (non-negative might 5920 - Prefix: "IP address" -> "IPv4 address" > Prefix: "enough trailing 5921 bits to" -> "the minimum number > of trailing bits needed to" 5923 fixed. 5925 > Section 4.4, Page 20: - "BGP does not use any TCP-based keep-alive 5926 > mechanism to determine if peers are reachable". Is it worth noting 5927 > that TCP may still timeout the connection even if TCP keepalives 5928 are > turned off? 5930 the text is fine as it is. 5932 > Section 4.4, Page 20: > KEEPALIVE message consists" -> "A KEEPALIVE 5933 message consists" fixed. 5935 > Section 5, Page 23: "The same attribute can not appear more than > 5936 once with the Path Attributes field...". Does this mean the same > 5937 attribute type, or the same attribute type and value? 5939 the former (the same attribute type). 5941 > Section 5.1 "The usage of each BGP path attributes .." -> > 5942 attribute 5944 fixed. 5946 > Section 5.1.3 "IP address" -> "IPv4 address" > > "A BGP speaker 5947 must never advertise an address of a peer to that > peer as a 5948 NEXT_HOP, for a route that the speaker is originating." > suggest 5949 replace this text with: > "A route originated by a BGP speaker must 5950 never be advertised to a > peer using an address of that peer as 5951 NEXT_HOP" 5953 fixed. 5955 > Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which 5956 > allows the MULTI_EXIT_DISC to be removed from a route." Might > 5957 want to say that this is dangerous unless you received the route > 5958 from an EBGP peer? 5960 think we should keep the text as is. 5962 > Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE > 5963 message that is received from an external peer, then this > attribute 5964 MUST be ignored by the receiving speaker, except for the > case of 5965 BGP Confederations [RFC3065]." > - "ignored" might be taken to mean 5966 that you don't process it for > decision, but that you propagate it 5967 to internal peers. I might > write "silently removed" or something 5968 similar. 5970 I think the text is ok as is. 5972 > Section 5.1.5, para 2. "set of AS" -> "set of ASs" 5974 fixed. 5976 > Section 6.3: wrt NEXT_HOP semantic correctness: should we check > 5977 that a NEXT_HOP is not a multicast or broadcast address? 5979 I'll add to the definition of NEXT_HOP that it is a unicast address. 5981 > Section 6.3, page 32, para 7: "peer than sent" -> "peer that > 5982 sent" 5983 fixed. 5985 > Section 6.3: "if any attribute appears more than once" - does this 5986 > mean the same attribute type, or the same attribute type and > 5987 value? 5989 the former. 5991 > Section 6.8 "Comparing BGP identifiers is done by treating them as 5992 > (4-octet-long) unsigned integers". Need to convert to host byte > 5993 order before comparing. 5995 fixed. 5997 > Section 6.8, item 2: "closes BGP connection" -> "closes the BGP > 5998 connection"; "accepts BGP connection" -> "accepts the BGP 5999 connection". 6001 fixed. 6003 > Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it 6004 > is unclear for IBGP connections how to determine "the neighbor AS > 6005 from which the other IBGP speaker learned the route". If this is > 6006 really the leftmost entry in the AS path (or the local AS if the > 6007 path is empty), the spec should explicitly say so. 6009 fixed. 6011 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6012 > attribute is removed before..." The first sentence is pretty > 6013 nearly incomprehensible. 6015 This topic has some more discussion surrounding what text we should 6016 use to clarify this issue. This is followed up in issue 18. 6018 > Section 9.1.2.2 (d) > "d) If at least one of the candidate routes 6019 was received from > an external peer in a neighboring autonomous 6020 system, remove > from consideration all routes which were received 6021 from > internal peers." > For consistency with (c) and clarity, this 6022 might be reworded: > "d) If any of the candidate routes was learned 6023 via EBGP, > remove from consideration all routes which were learned 6024 by > IBGP." 6026 fixed. 6028 > Section 9.1.2.2 (e) > "cost (n) is better than cost (m)" > Given 6029 the definition of cost, it might be clearer to say > "cost (n) is 6030 lower than cost (m)" 6031 fixed. 6033 > Section 9.1.2.2 (g) > "neighbor address" has not been defined. 6035 I'll replace "neighbor address" with "peer address". 6037 > Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes 6038 > of all routes to be aggregated should be ignored." > > Perhaps 6039 "ignored" is ambiguous here, and it's not clear > whether should is a 6040 SHOULD. Suggest: > > "Any AGGREGATOR attributes from the routes to 6041 be aggregated > MUST NOT be included in the aggregated route." fixed. 6043 > Section 9.3 - shouldn't this subsection be moved to the discussion 6044 > of Phase 1 or Phase 2 of the decision process? Or at least move it 6045 > before Section 9.2. 6047 I think it is fine where it is now. 6049 > Appendix E, para 2: IP precedence has been deprecated. Delete > 6050 this paragraph, or replace with appropriate diffserv codepoint. 6052 deleted. 6054 > Security Considerations: > "BGP supports the ability to 6055 authenticate BGP messages by using > BGP authentication." > This 6056 sentence should be removed, and the Authentication > Information 6057 parameter has been deprecated. 6059 Please see the recent e-mail exchange on the Security Considerations 6061 See issue 19 for more on the Security Considerations section of the 6062 draft. 6064 These topics were discussed in the "proxy: more comments on the draft 6065 -18" thread. 6067 3.17. Section 3, Page 8, Paragraph 3 - Obsolete? 6069 Status: Consensus 6070 Change: Yes 6071 Summary: Leave the current definition of BGP Speaker, and normalize 6072 the text to use "BGP Speaker" instead of router. 6074 Discussion: 6076 This issue was spawned from the discussions in issue 16, 6077 specifically: 6079 Anonymous reviewer: 6081 > Section 3, page 8, para 3 - "The hosts executing..." This > 6082 paragraph seems obsolete. 6084 Yakov: 6086 I'll take it out. 6088 With regard to this, Siva asked if some route optimization vendors 6089 rely on this. 6091 Jeff replied: 6093 To provide context, this paragraph currently reads: 6095 : The hosts executing BGP need not be routers. A non-routing host : 6096 could exchange routing information with routers via EGP [RFC904] : or 6097 even an interior routing protocol. That non-routing host could : 6098 then use BGP to exchange routing information with a border router : 6099 in another Autonomous System. The implications and applications of : 6100 this architecture are for further study. .in 4 There are several 6101 deployed entities that could be considered to "exploit" this 6102 paragraph. Route collectors, route servers, bandwidth shapers and 6103 other optimizers. However, the original text may be showing its age 6104 a little bit. 6106 Perhaps the following might be a bit more appropriate: 6108 "The hosts executing BGP need not be routers. A non-routing host may 6109 exchange routing information with a BGP speaker for reasons that are 6110 outside the scope of this document." 6112 I would also propose adding to the same paragraph (but could be 6113 persuaded to drop it since it is *logically* redundant): "These non- 6114 routing hosts should exercise great care not to insert themselves 6115 into the forwarding path if they re-announce BGP routes." 6117 Yakov replied: 6119 Since operations of non-routing host are outside the scope of the 6120 document, and since the document doesn't preclude non-routing hosts 6121 to run BGP, I would prefer just to take the following paragraph out, 6122 and not to add any new text. 6124 The hosts executing BGP need not be routers. A non-routing host 6125 could exchange routing information with routers via EGP [RFC904] or 6126 even an interior routing protocol. That non-routing host could then 6127 use BGP to exchange routing information with a border router in 6128 another Autonomous System. The implications and applications of this 6129 architecture are for further study. 6131 Jeff replied that this was ok, and instead suggested: 6133 At the beginning of the document, we define: BGP speaker A router 6134 that implements BGP. 6136 This (potentially) restricts a speaker to being a router. 6137 Additionally, several spots in the text where we probably should say 6138 "BGP speaker", we use router. 6140 Yakov agreed to add this definition. 6142 Jeff replied that there still was a problem with this definition 6143 being too limiting. The discussion meandered off list for a couple 6144 of exchanges and these additional definitions were proposed: 6146 First Jeff proposed this: 6148 "A router that implements the BGP protocol. Non-routing hosts that 6149 also implement BGP are out of scope of this document." 6151 Then Andrew replied, that we should make sure the definition does not 6152 opt out entirely from making sure that non-routing hosts are 6153 interoperable: 6155 BGP Speaker .in 7 A router that implements the BGP protocol. The 6156 internal behavior of non-routing hosts that also implement BGP are 6157 out of scope of this document. However, in their interactions with 6158 routers, non-routing hosts must behave as if they were routers. 6160 And Jeff replied: 6162 BGP Speaker .in 7 A router that implements the BGP protocol. The 6163 internal behavior of non-routing hosts that also implement BGP are 6164 out of scope of this document. However, in their interactions with 6165 BGP speaking routers, non-routing hosts that implement BGP should be 6166 indistinguishable from a router on the wire. .in 4 6168 (or something like that - s/on the wire/ with whatever sounds best.) 6170 IOW, look like bgp on the wire - what you do internally is out of 6171 scope. 6173 Yakov replied, that we should keep the current definition, since it 6174 is clear that non-routing hosts are outside of the scope. Jeff 6175 responded that he is ok with that if we normalize the use of "BGP 6176 Speaker" instead of "BGP router" in the document. Yakov agreed to 6177 this, we are at consensus on this. 6179 This was discussed in the "proxy: more comments on draft -18" thread. 6180 And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - 6181 Obsolete?" thread. And also, the "issue 17 - final resolution" 6182 thread. 6184 3.18. MED Removal Text 6186 Status: Consensus 6187 Change: Yes 6188 Summary: Use text at the end of the discussion. 6190 Discussion: 6192 This issue is spawned from issue 16. 6194 An anonymous reviewer pointed out: 6196 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6197 > attribute is removed before..." The first sentence is pretty 6198 nearly > incomprehensible. 6200 Yakov replied: 6202 here is my attempt to clarify this: 6204 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6205 route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 6206 attribute may only be considered in the comparison of EBGP learned 6207 routes; the attribute is then removed, and then the remaining EBGP 6208 learned routes may be compared to the remaining IBGP learned routes, 6209 without considering the MULTI_EXIT_DISC attribute for those EBGP 6210 learned routes whose MULTI_EXIT_DISC attribute will be removed before 6211 advertising these routes to IBGP. 6213 Any further suggestions on how to improve this would be appreciated. 6215 Siva replied: 6217 How about this: 6219 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6220 route into IBGP, then comparison based on the MULT_EXIT_DISC 6221 attribute may (MUST?) be performed only among the EBGP learned 6222 routes. This comparison MUST be performed before the removal of the 6223 MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then be 6224 removed from those EBGP routes where such removal is required and 6225 which are still eligible. This is followed by comparison with IBGP 6226 learned routes. 6228 I think this reflects our objectives, which is: 6230 a) If MED is to be removed, compare EBGP routes based on the MED 6232 b) Then remove the MED 6234 c) Then do comparison with IBGP routes 6236 Andrew suggested: 6238 If a router is configured to remove a MULTI_EXIT_DISC attribute from 6239 a route learned from EBGP, before re-advertising it into IBGP the 6240 router MUST compare the route with other EBGP-learned routes before 6241 removing the MULTI_EXIT_DISC. Once this comparison is complete, the 6242 MED may be removed, and any remaining routes can be compared with 6243 IBGP routes to determine the best route. 6245 Yakov replied: 6247 Here is the text that will go in the next version of the draft: 6249 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6250 route into IBGP, then comparison based on the MULT_EXIT_DISC 6251 attribute MAY be performed only among the EBGP learned routes. This 6252 comparison MUST be performed before the removal of the 6253 MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then 6254 removed from those EBGP routes where such removal is required and 6255 which are still eligible. This is followed by comparison with IBGP 6256 learned routes. 6258 Matthew responded to this with: 6260 I think this new text is ambiguous. 6262 >Here is the text that will go in the next version of the draft: > > 6263 If a MULTI_EXIT_DISC attribute is removed before re-advertising a > 6264 route into IBGP, then comparison based on the MULT_EXIT_DISC > 6265 attribute MAY be performed only among the EBGP learned routes. 6267 .in 4 This could be taken to mean either that the comparison may be 6268 performed, and if it's performed it must be performed only between 6269 EBGP learned routes, or that the comparison must be performed, but it 6270 may be performed only between EBGP learned routes. 6272 > This comparison MUST be performed before the removal of the > 6273 MULTI_EXIT_DISC attribute. 6275 .in 4 If doing the comparison is optional, then I think that this 6276 sentence should read "If the comparison is performed, then it MUST be 6277 perfo..." 6279 > The MULT_EXIT_DISC attribute is then > removed from those EBGP 6280 routes where such removal is required and > which are still eligible. 6281 This is followed by comparison with > IBGP learned routes. 6283 6285 I think that it is desirable for an operator to be able to turn off 6286 MED processing entirely (including turning off all MED based 6287 comparisons), so I would suggest the following text: 6289 .in 5 If a MULTI_EXIT_DISC attribute is removed before re-advertising 6290 a route into IBGP, comparison based on the received MULTI_EXIT_DISC 6291 attribute MAY be performed. If an implementation chooses to perform 6292 this comparison, then the comparison MUST be performed only among 6293 EBGP learned routes, and it MUST be performed before the removal of 6294 the MULTI_EXIT_DISC attribute. 6296 Curtis replied to Yakov's message: 6298 .in 4 Looks good to me. 6300 I see no need to change "This comparison MUST be performed before the 6301 removal of the MULTI_EXIT_DISC attribute". There is no implication 6302 that MULTI_EXIT_DISC must be removed and the first sentence clearly 6303 indicates that doing so is not required therefore no ambiguity. 6304 Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second 6305 sentence would be redundant. 6307 After some further discussion we have reached full consensus with: 6309 .in 4 If a MULTI_EXIT_DISC attribute is removed before re-advertising 6310 a route into IBGP, then comparison based on the received EBGP 6311 MULTI_EXIT_DISC attribute MAY still be performed. If an 6312 implementation chooses to remove MULTI_EXIT_DISC, then the optional 6313 comparison on MULTI_EXIT_DISC if performed at all MUST be performed 6314 only among EBGP learned routes. The best EBGP learned route may then 6315 be compared with IBGP learned routes after the removal of the 6316 MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a 6317 subset of EBGP learned routes and the selected "best" EBGP learned 6318 route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC 6319 must be used in the comparison with IBGP learned routes. For IBGP 6320 learned routes the MULTI_EXIT_DISC MUST be used in route comparisons 6321 which reach this step in the decision process. 6323 This is discussed in the "proxy: more comments on draft 18" thread. 6324 And in the "issue 18" thread. 6326 3.19. Security Considerations 6328 Status: Consensus 6329 Change: Yes 6330 Summary: Fix Security Considerations section to include mandatory MD5 6331 auth and advance security considerations draft along with the base 6332 draft. 6334 Discussion: 6336 Yakov started this discussion by proposing text which would require 6337 TCP MD5 authentication for BGP implementations. This is to bring the 6338 spec in line with an IETF requirement that authentication be 6339 available. 6341 After some discussion the plan is to advance 6342 draft-ietf-idr-bgp-vuln-00.txt as Informational along with the base 6343 BGP specification. This draft will serve as the security analysis 6344 section of the base spec. 6346 This is discussed in the "revised Security Considerations section" 6347 thread. 6349 3.20. Peer Oscillation Damping 6351 Status: Consensus 6352 Change: No 6353 Summary: Keep the Peer Oscillation Damping reference in the 6354 specification. 6356 Discussion: 6358 This began when Siva proposed: 6360 .in 4 Since this feature is going to be added in a new draft, and its 6361 addition will change the operation of the state machine, can we 6362 remove all mention of it in the state machine ? As part of this 6363 removal, can we also remove the IdleHold Timer from the FSM since it 6364 is not useful in the absence of peer oscillation damping ? 6366 The draft that describes this procedure can then describe the change 6367 in the state machine required to do this. 6369 Sue replied that: 6371 The reason we should not remove the peer oscillation damping from the 6372 state machine: 6374 1) Deployed implementations support peer oscillation damping 2) Hooks 6375 for the additions in the FSM cannot be added later. 6377 These hooks are optional and do not need to be implemented. 6379 Siva replied: 6381 I understand. I am not trying to object to peer oscillation damping, 6382 I think it is a good idea and we have included it in our 6383 implementation as well. I was suggesting that instead of a partial 6384 description in this draft, it be completely described in the draft on 6385 peer oscillation damping. 6387 However, I do see your point, and unless there are any objections 6388 from others, I think we have consensus on this issue. 6390 This was discussed in the "Response to FSM input - Comments 1-10" 6391 thread: Comment #1. 6393 3.21. Session Attributes - IdleHold Timer 6395 Status: Consensus 6396 Change: Yes 6397 Summary: Add the text in the discussion section. 6399 Discussion: 6401 This discussion began with Siva asking: 6403 .in 4 Why have a Hold Timer and a Hold Time ? Can we replace this 6404 with just Hold timer ? 6406 Can we also add the following session attributes: 6408 a) DelayBgpOpenTimer b) IdleHold Timer (in case we choose not to 6409 remove this from the base FSM) 6411 Can we also add the following flag to the session attributes: a) 6412 DelayOpen Flag 6414 After some discussion we have this text on the table: 6416 Event8: Idle hold timer expires 6417 Definition: An Event generated when the Idle Hold Timer expires. The 6418 Idle Hold Timer is only used when the persistent peer oscillation 6419 damping function is enabled. 6421 % Implementations not implemented persistent % peer oscillations 6422 damping functions may not % have the Idle Hold Timer. Sue replied: 6424 I will accept the new text for the following total text: Event8: Idle 6425 hold timer expires 6427 Definition: An event generated when the Idle Hold Timer .in 24 6428 expires indicating that the session has completed a back-off period 6429 to prevent bgp peer oscillation. 6431 The Idle Hold Timer is only used when the persistent peer oscillation 6432 damping function is enabled. 6434 Implementations not implementing the persistent peer oscillation 6435 damping functions may not have the Idle Hold Timer. 6437 Status: Optional 6439 We are at consensus with this. 6441 Tom added a couple of minor edits, correcting the spelling of 6442 "persistent" in the third paragraph, and pointing out that: 6444 .in 4 oscillation damping functions may not have the Idle Hold ** 6445 function ** (because we only have function not functions in the 6446 previous sentence) Timer. 6448 Sue added the edits. 6450 Siva also liked the way this issue has turned out. 6452 This was discussed in the "Response to FSM input - Comments 1-10" 6453 thread: Comment #2. And in the "Draft 19 - issue #21" thread, 6454 alternately the "Draft 19 - Issue 21" thread. 6456 3.22. Specify New Attributes (Accept Connections/Peer Oscillation 6457 Damping) 6459 Status: Consensus 6460 Change: Yes 6461 Summary: Add the text in the discussion section to section 8.0. 6463 Discussion: 6465 This began with Siva proposing: 6467 Can we call these out as well: 6469 * Accept Connections from unconfigured peers (Enabled/Disabled) * 6470 Peer Oscillation Dampening (Enabled/Disabled) (In case we choose not 6471 to remove it from base spec) 6473 After some discussion we have this text on the table: 6475 The following will be added to 8.0 Optional parameters that may be 6476 supported either per connection or per implementation: 6478 1) Delay Open flag 2) Delay Open Timer 3) Perform automatic start 6479 flag 4) Passive TCP establishment flag 5) BGP stop_peer_flag flag 6) 6480 Idle Hold timer 7) Perform automatic stop flag 8) Perform Collision 6481 detect in Establish mode flag 6483 Sue accepted these changes. 6485 Tom added this correction for item 2 in Sue's text: 6487 2) Delay Open Timer 6489 ** Open Delay timer ** (for which we have consensus in Issue list v2 6490 item 7) 6492 Siva asked, and Sue accepted these additional changes: 6494 9) accept connections from un-configured peers 5) BGP stop_peer_flap 6495 flag 6497 We are at consensus on this. 6499 This was discussed in the "Response to FSM input - Comments 1-10" 6500 thread: Comment #3. This was also discussed in the "BGP Draft 19 - 6501 Close open items 22" thread. 6503 3.23. Event1/Event2 Clean Up 6505 Status: Consensus 6506 Change: Yes 6507 Summary: Use "Local system administrator" in both sections. 6509 Discussion: 6511 Siva proposed that we clean up the text for these Events by selecting 6512 either "Administrator" or "Local system" but not both. 6514 Sue proposed text using "Local system administrator" that was agreed 6515 on. 6517 This was discussed in the "Response to FSM input - Comments 1-10" 6518 thread: Comment #4. 6520 3.24. Events 3, 5, 6 & 7 Give Examples 6522 Status: Consensus 6523 Change: No 6524 Summary: Leave the examples out. 6526 Discussion: 6528 This began with Siva proposing we add examples for these event 6529 states. Sue believes this is largely out-of-scope, but did agree to 6530 move the example of "automatic stop" to the event description 6531 section. She asked for proposed text for additional examples. 6533 Sue replied that she has made the following changes, and asked if 6534 these worked for Siva. 6536 New text: Event7: Automatic stop 6538 Definition: Local system automatically stops the BGP connection. 6540 An example of an automatic stop event is exceeding the number of 6541 prefixes for a given peer and the local system automatically 6542 disconnecting the peer. 6544 Status: Optional depending on local system 6546 Siva thought this for Event 7 was fine. 6548 Sue replied to the list, saying that, previously examples had caused 6549 dissension, and asked if there was a strong feeling either way. 6551 Siva proposed this text for Events 3, 5 & 6: 6553 Event 3: Examples of this event are: When a connection is terminated 6554 during exchange of Open messages due to version failure 6556 Event 5: Examples of this event are: Similar to Event 3 6558 Event 6: Examples of this event are: Similar to Event 3 and b) When a 6559 Idle Hold timer expires (within local limit) 6561 Sue replied to this: 6563 I'm going to leave the examples out of events 3, 4, 6 since I've not 6564 heard any strong input on the mail list **and** I had strong comments 6565 on prior versions of the draft. I'd like to declare that issue 24 6566 has consensus. 6568 Siva agreed, we are at consensus on this issue. 6570 This was discussed in the "Response to FSM input - Comments 1-10" 6571 thread: Comment #5. This was also in the "Issue 25" thread, and the 6572 "Issue 25 - this is really issue 24" threads. This is also in the 6573 "Draft 19 - Issue 24" thread. 6575 3.25. Event 4 & 5 Session Initiation Text 6577 Status: Consensus 6578 Change: No 6579 Summary: Leave the text as is. 6581 Discussion: 6583 This began with Siva wanting to change: 6585 Definition: Local system automatically starts the BGP session with 6586 the passive flag enabled. The passive flag indicates that the peer 6587 will listen prior to establishing a connection. 6589 to: 6591 The passive flag indicates that the state machine will wait for 6592 specified peer to initiate a connection with the local system. If 6593 this does not happen within a specific time (hold time), the local 6594 system will then also attempt to initiate connection with the 6595 specified peer. 6597 Sue replied: 6599 The text in 8.2.1.1 indicates the definition of the passive flag. 6a) 6600 ========== My understanding of your text is that you want to replace 6601 in both sets of text: 6603 "The passive flag indicates the peer will listen prior to 6604 establishing a connection". 6606 with: 6608 "The passive flag indicates that the state machine will wait for the 6609 specified peer to initiate a connection with a local system. 6611 The problem with this sentence is that in the "unconfigured" case the 6612 phrase "specified" peer is confusing. I think the original text is 6613 clearer. 6615 6b) ========== If this does not happen within a specific time (hold 6616 time), the local system will then also attempt to initiate (a) 6617 connection with the specified peer. My comments: Again, the 6618 "specified peer" term is confusing. Also, the 2nd half of the 6619 statement mixes the actions of the state machine with the events. I 6620 believe this muddies the text instead of clarifying it. 6622 Siva and Sue later agreed to leave the text the same because of the 6623 Unconfigured + passive TCP connection + Delay Open situation. 6625 This was discussed in the "Response to FSM input - Comments 1-10" 6626 thread: Comment #6. 6628 3.26. Event 4 & 5 - bgp_stop_flap option 6630 Status: Consensus 6631 Change: Yes 6632 Summary: Add new event below. 6634 Discussion: 6636 This began with Siva asking: 6638 Won't a variant of this with bgp_stop_flap option set be required ? 6639 We can also achieve the same by using the bgp_stop-Flap option as a 6640 flag that is provided as an input to the state machine. 6642 Siva later clarified this to include: 6644 We already have Event 3 - Automatic Start Event 5 - Automatic start 6645 with bgp_stop_flap option set To make things consistent, shouldn't we 6646 either a) Add 3 new events : .in 24 1) Manual start with bgp_stop 6647 flap option set 2) Manual start with passive TCP establishment and 6648 bgp_stop_flap option set 3) Automatic start with passive TCP 6649 establishment and bgp_stop_flap option set 6651 or b) Remove Event 6, and rely on a flag to tell us wither peer flap 6652 damping is to be performed for the session or not. 6654 Sue said she preferred option A. And stated that #1 & #2 are 6655 infeasible, but that we need to add #3. 6657 Tom replied: 6659 .in 4 But if we add an event, then we must add and agree on actions 6660 for all six existing states so I think to say that adding a new event 6661 settle things might be naive. 6663 If we do add 3) Automatic start with passive TCP establishment and 6664 bgp_stop_flap option set 6666 which I understand is Sue's resolution, then for Idle state the 6667 actions are straightforward but for the other five, is the event 6668 completely ignored? If so, does it mean that the passive flag and 6669 the bgp_stop_flap option are ignored and we carry on as if we were 6670 when we were started which may have been without them. Or is the 6671 fact of starting ignored but the flags remain set and so color the 6672 effect of other events? Needs defining. 6674 Jeff replied to this, quoting the existing draft: 6676 The start events [Event 1, 3-6] are ignored in connect state. 6678 The start events [Event1, 3-6] are ignored in the Active state. 6680 The Start events [Event1, 3-6] are ignored in the OpenSent state. 6682 Any start event [Event1, 3-6] is ignored in the OpenConfirm state. 6684 Any start event (Event 1, 3-6) is ignored in the Established state. 6686 And elaborated, saying that: 6688 .in 4 "ignore" means do nothing. This means don't twiddle with the 6689 flags. :-) 6691 The text that was finally agreed on is: 6693 Event 7: Automatic start with bgp_stop flap option set and passive 6694 TCP establishment option set Definition: Local system automatically 6695 starts the .in 24 BGP peer connection with peer oscillation damping 6696 enabled and passive TCP establishment enabled. The exact method of 6697 damping persistent peer oscillations is left up to the 6698 implementation, and is outside the scope of this document. 6700 Status: Optional, used only if the bgp peer has .in 24 enabled bgp 6701 peer oscillation damping with following optional flags settings 6702 below. 6704 Optional attributes: 1) Perform automatic start flag SHOULD be set 2) 6705 BGP stop_peer_flap flag SHOULD be set I've re-ordered the Timer 6706 events to keep the text changes down to a minimum. 6708 action 9 - connect retry timer action 10 - Hold Timer expires action 6709 11 - Keepalive timer expires action 13 - Open Delay timer expires 6710 action 14 - Idle Hold timer expires 6712 All other events are incremented by 1 6714 This was discussed in the "Response to FSM input - Comments 1-10" 6715 thread: Comment #7. 6717 3.27. Event 5 Clarification 6719 Status: Consensus 6720 Change: No 6721 Summary: Leave the text as is. 6723 Discussion: 6725 This began when Siva asked that in event 5: 6727 .in 4 Is it correct that this event will occur only when we want to 6728 restart a connection (after it had been terminated due to some reason 6729 beside administrative action) that we had accepted from an 6730 unconfigured peer ? 6732 Sue replied: 6734 .in 4 The automatic start function is an implementation specific 6735 mechanism. This text does not seek to restrict it in any fashion. 6737 Siva said that although he felt his original clarification would be 6738 more useful to new implementors he is ok with the text as is. 6740 This was discussed in the "Response to FSM input - Comments 1-10" 6741 thread: Comment #8. 6743 3.28. Timer Events Definition - Make Consistent 6745 Status: Consensus 6746 Change: Yes 6747 Summary: Change text to use "generate" across the board. 6749 Discussion: 6751 Can we use similar language for Events 8-12 to make them consistent? 6753 It was agreed that we will use "generate" i.e.: 6755 Event 8: An event generated when the Idle Hold timer expires. Event 6756 9: An event generated when the ConnectRetry timer expires. Event 10: 6757 An event generated when the Hold timer expires. Event 11: An event 6758 generated when the Keepalive timer expires Event 12: An event 6759 generated when the Delay BGP Open timer expires. This is at 6760 consensus. 6762 This was discussed in the "Response to FSM input - Comments 1-10" 6763 thread Comment #9. 6765 3.29. Event 8 - Clean Up 6767 Status: Consensus 6768 Change: Yes 6769 Summary: Clean up first sentence. New text below. 6771 Discussion: 6773 Siva began this by asking if we could clean up the wording of Event 6774 8. 6776 After some discussion with Sue we are at this change for the first 6777 sentence: 6779 An event triggered by the expiry of the Idle Hold timer, indicating 6780 that the session has completed waiting for a back-off period to 6781 prevent bgp peer oscillation. 6783 This was discussed in the "Response to FSM input - Comments 1-10" 6784 thread: Comment #10. 6786 3.30. Hold Timer - Split? 6788 Status: Consensus 6789 Change: No 6790 Summary: Keep the hold timer text as is. 6792 Discussion: 6794 Siva proposed that since: 6796 .in 4 We use the hold timer for two purposes 6798 * Waiting for an open message (with a default value of 240 seconds) * 6799 Waiting for Keepalives (with a default value of 90 seconds) 6801 Can we use two different timers (or at least call them two different 6802 timer events) ? 6803 Sue replied that this is not how it is implemented currently. Siva 6804 replied that we have two conceptually different timers, but that it 6805 would certainly work to only have one, since only one needs to be 6806 running at any given time. 6808 Tom agreed that we can keep things as is. 6810 This was discussed in the "Comments 11-20" thread: Comment #11. 6812 3.31. OpenDelay Timer Definition 6814 Status: Consensus 6815 Change: Yes - See issue 28 6816 Summary: This is fixed by the fixing of issue 28. 6818 Discussion: 6820 This began with Siva's request that we add something to Event 12 to 6821 specify what to do when the timer expires. This seems to have been 6822 addressed in issue 28. 6824 This was discussed in the "Comments 11-20" thread: Comment #12. 6826 3.32. Definition of TCP Connection Accept (Event 13) 6828 Status: Consensus 6829 Change: Yes 6830 Summary: Change "Definition" text as indicated below. 6832 Discussion: 6834 Siva proposed that we change text from referring to "TCP connection 6835 request" to "receiving a TCP connection". This led to this proposed 6836 text: 6838 Definition: Event indicating the reception of a TCP connection 6839 request with a valid source IP address and TCP port, and valid 6840 destination IP address and TCP Port. The definition of invalid 6841 source address and port and invalid destination address is left to 6842 the implementation. 6844 This met with agreement. 6846 This thread also discussed the idea of filtering the incoming 6847 address/port. It was decided that this was implementation dependent. 6849 This was discussed in the "Comments 11-20" thread: Comment #13. 6851 3.33. Event 13 & 14 - Valid Addresses & Ports 6853 Status: Consensus 6854 Change: Yes 6855 Summary: See text at the end of the discussion. 6857 Discussion: 6859 With regard to Event 13 & 14, Siva raised questions about: 1) What 6860 does it mean to validate a port, and 2) Should we state what we 6861 consider an invalid IP address to be? 6863 Sue replied that this is local policy and is implementation 6864 dependent. Siva agreed regarding the source port & IP address, but 6865 disagreed about the destination port. He argued that we need to know 6866 the destination port for interoperability. 6868 Sue asked Siva to provide some text. 6870 After a long lull, Sue replied with: 6872 I would like to keep the current text of "Should" in the following 6873 text "BGP's destination port SHOULD be port 179 as defined by IANA." 6875 Should indicates that it normally should be 179. If an 6876 implementation allows for an alternative TCP port, it is still valid 6877 as the "MUST" is not indicated. 6879 There have been no further comments on this, the chairs have decided 6880 to close it. 6882 This was discussed in the "Comments 11-20" thread: Comment #14. This 6883 was also in the "BGP-19: Issue 33" thread. 6885 3.34. Event 17 - TCP Connection Fails to TCP Connection Termination 6887 Status: Consensus 6888 Change: Yes 6889 Summary: Change the text to "fails." 6891 Discussion: 6893 This began with Siva observing: 6895 .in 4 This event can occur even when the transport connection is 6896 closed by the other end. Since this does not reflect a 'failure ', 6897 can we change the event name to 6898 % Event17: TCP connection termination 6900 Sue replied that: 6902 Discussion: It both terminates from the remote site and can "timeout" 6903 - fail. Suggestions? I can use "disconnect", what do you think. 6905 Siva replied that this was a minor issue, and on further reflection, 6906 either "fails" or "disconnect" would be acceptable. 6908 Sue replied that she has accepted Siva's comments, and the text will 6909 be changed to "fails". 6911 This was discussed in the "Comments 11-20" thread: Comment #15. This 6912 was also discussed in the "BGP-19: Issue 34-35, 40-48" thread. 6914 3.35. Making Definition Style Consistent 6916 Status: Consensus 6917 Change: Yes 6918 Summary: Adopt consistent style for the definition of events. 6920 Discussion: 6922 This started with Siva asking if we could make the definition style 6923 consistent across events. Sue replied to this with text for 13-17, 6924 Siva clarified that he was talking more about 18-21, and proposed 6925 text. 6927 We are agreed on the text for 13-17: 6929 Event13: TCP connection indication and valid remote peer 6931 Definition: Event indicating the local system reception .in 24 of a 6932 TCP connection request with a valid source IP address and TCP port, 6933 and valid destination IP address and TCP Port. The definition of 6934 invalid source, and invalid destination IP address is left to the 6935 implementation. 6937 BGP's destination port SHOULD be port 179 as defined by IANA. 6939 TCP connection request is denoted by the local system receiving a TCP 6940 SYN. 6942 Status: Mandatory (Optional) 6944 Event14: RCV TCP connection indication with invalid source or 6945 destination Definition: Event indicating the local system reception 6946 of a TCP connection request with either an invalid source address or 6947 port number or an invalid destination address or port number. BGP 6948 destination port number SHOULD be 179 as defined by IANA. 6950 Again, a TCP connection request denoted by local system receiving a 6951 TCP SYN. Status: Mandatory (Optional) Event15: TCP connection 6952 request sent received an ACK. 6954 Definition: Event indicating the Local system's request to establish 6955 a TCP connection to the remote peer. The local system's TCP session 6956 sent a TCP SYN, and received a TCP SYN, ACK pair of messages, and 6957 Sent a TCP ACK. Status: Mandatory Event16: TCP connection confirmed 6958 Definition: Event indicates that the local system receiving a 6959 confirmation that the TCP connection has been established by the 6960 remote site. 6962 The remote peer's TCP engine sent a TCP SYN. The local peer's TCP 6963 engine sent a SYN, ACK pair, and now has received a final ACK. 6964 Status: Mandatory Event17: TCP connection fails Definition: Event 6965 indicates that the local system has received a TCP connection failure 6966 notice. 6968 The remote BGP peer's TCP machine could have sent a FIN. The local 6969 peer would respond with a FIN-ACK. Another alternative is that the 6970 local peer indicated a timeout in the TCP session and downed the 6971 connection. Status: Mandatory 6973 Siva proposed these changes for 18-21: 6975 Event18: BGPOpen Definition: An event indicating that a valid Open 6976 message has been received. 6978 with Event18: BGPOpen Definition: An event is generated when a valid 6979 Open message has been received. 6981 Event19: BGPOpen with BGP Delay Open Timer running Definition: An 6982 event indicating that a valid Open message has been successful 6983 established for a peer that is currently delaying the sending of an 6984 BGP Open message. 6986 with 6988 Event19: BGPOpen with BGP Open Delay Timer running Definition: An 6989 event is generated when a valid Open message has been received for a 6990 peer that is currently delaying the sending of a BGP Open message. 6992 Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer" 6993 per issue 7. Event20: BGPHeaderErr Definition: BGP message header is 6994 not valid. 6996 with 6998 Event20: BGPHeaderErr Definition: An event is generated when a 6999 received BGP message header is not valid. 7001 Event21: BGPOpenMsgErr Definition: An BGP Open message has been 7002 received with errors. 7004 with Event21: BGPOpenMsgErr Definition: An event is generated when 7005 BGP Open message with errors has been received. 7007 Sue replied that she accepted Siva's comments, so we are at consensus 7008 here. 7010 This was discussed in the "Comments 11-20" thread: Comment #16. This 7011 also came up in the "BGP-19: Issue 34-35, 40-48" thread. 7013 3.36. Event 19 - Definition Cleanup 7015 Status: Consensus 7016 Change: Yes 7017 Summary: Replace definition for Event 19 with the text in the 7018 discussion. 7020 Discussion: 7022 Siva proposed we replace: 7024 .in 4 Definition: An event indicating that a valid Open Message has 7025 been successful established for a peer that is currently delaying the 7026 sending of an BGP Open message. 7028 with: 7030 .in 4 Definition: An event indicating that a valid OPEN Message has 7031 been received for a peer that has a successfully established 7032 transport connection and is currently delaying the sending of a BGP 7033 open message 7035 in Event 19. Sue agreed to the changes. 7037 This was discussed in the "Comments 11-20" thread: Comment #17. 7039 3.37. Event 22 - Cleanup 7041 Status: Consensus 7042 Change: Yes 7043 Summary: Replace Event 22 definition with the text from the 7044 discussion. 7046 Discussion: 7048 Siva began with observing: 7050 Event22: Open collision discard Definition: An event generated 7051 administratively when a connection Collision has been detected while 7052 processing an incoming Open message. This connection has been 7054 Isn't this event 'automatically' generated, since it is a system 7055 generated event ? 7057 Sue replied that: 7059 response: How this generated is implementation specific. The 7060 "administratively" is to cover policy. 7062 Siva also proposed an editorial fix with: 7064 Event 22 is an administrative could occur if FSM is implemented as 7065 two 7067 The word event is missing. How about 7069 Event 22 is an automatic event that could occur if FSM is implemented 7070 as two 7072 Sue replied with this rewritten text: 7074 Event22: Open collision dump Definition: An event generated 7075 administratively when a connection collision has been detected while 7076 processing an incoming OPEN message and this connection has been 7077 selected to disconnected. See Section 6.8 for more information on 7078 collision detection. 7080 Event22 is an administrative based only implementation specific 7081 policy. This Event may occur if the FSM is implemented as two linked 7082 state machines. 7084 Siva agreed with this new text. 7086 This was discussed in the "Comments 11-20" thread: Comment #18. 7088 3.38. FSM Description - ConnectRetry Count 7090 Status: Consensus 7091 Change: No 7092 Summary: Leave the counter text alone, since it is used in peer 7093 oscillation and will be in the MIB. 7095 Discussion: 7097 Siva opened with this question: 7099 The Connect Retry count is updated by the FSM but never used. In the 7100 absence of peer oscillation damping, will this be used to stop 7101 connection establishment attempts after a certain maximum number ? 7103 Yes, this is either implementation specific or is it based on 7104 the peer oscillation damping draft. 7106 Can we include the use of this counter in some place ? 7108 Connect retry counter 1) Will be utilized by the peer 7109 oscillation damping draft. 2) Will be included in bgp-4-mibv2-xx. I 7110 just check and I didn't find it. 7112 Do you still want text in the main? 7114 To which Siva replied that he believes we can leave the main text 7115 alone. 7117 This was discussed in the "Comments 11-20" thread: Comment #19. 7119 3.39. Handling Event 7 (Auto Stop) to Idle State processing 7121 Status: Consensus 7122 Change: Yes 7123 Summary: Fix the text as indicated in the discussion. 7125 Discussion: 7127 Siva began with: 7129 .in 4 The handling of Event 7 is missing from the Idle State 7130 processing. Can we add this ? How about replacing 7132 An manual stop event (Event2) is ignored in the Idle state. 7134 with 7135 Manual stop (Event 2) and Auto stop (Event 7) events are ignored in 7136 the Idle state 7138 Sue replied that she would add the text. 7140 This was discussed in the "Comments 11-20" thread: Comment #20. 7142 3.40. Clearing the Connection Retry Timer 7144 Status: Consensus 7145 Change: No 7146 Summary: Leave things alone, since it is better to be redundant than 7147 to let something slip through. 7149 Discussion: 7151 Siva opened with the observation: 7153 .in 4 There are a few sections where the FSM draft states that the 7154 Connection Retry timer needs to be reset, whereas the connect retry 7155 timer had been cleared prior to entering that state. We can remove 7156 these instructions to clear the connect retry timer. 7158 List of places where the connect retry timer need not be cleared 7160 a) Handling of Event 19 in the Connect State b) Handling of Events 12 7161 in the Active State c) All cases where it is referred to in the 7162 OpenSent, OpenConfirm and Established states 7164 Sue replied: 7166 Comment: 1) Does it hurt to have the connect retry timer cleared at 7167 these points, since it has already been cleared. 7169 I felt it eased the implementations to allow the action routines to 7170 be shared across as many states as possible. You can see this a bit 7171 more actively. 7173 Tom replied to this: 7175 .in 4 I propose we leave it in and close this issue. 7177 1) To take out an action as redundant you need to be supremely 7178 confident that it really cannot make a difference. I am not 7179 (supremely confident); rather, the more I look at the FSM, the more 7180 places I find where actions are missing, as I have posted to the 7181 list, from obscure yet possible sequences of events and timing. And 7182 there is an outstanding issue of mine which flagged seven places 7183 where the next state was missing and so I think it impossible for any 7184 one to be confident that any particular action is redundant until 7185 that is cleared up and that is proving complex in some cases. So, 7186 play safe, keep them in. 7188 2) The argument for removing them is that the number of possible 7189 distinct action lists is increased. True - it will mean that an 7190 implementor will have to code more code when first implementing BGP. 7192 For me this is no contest; keeping it safe at the possible cost of 7193 redundancy outweighs the one-off cost of additional implementation. 7195 So keep the actions in and close the issue. 7197 Jeff replied that he agreed with Tom on this. 7199 Siva concurred, that this approach was acceptable. 7201 Unless someone objects, this issue is at consensus. 7203 This was discussed in the "Comments 21-30" thread: Comment #21. This 7204 is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry 7205 timer" thread. 7207 3.41. Handling of Event 14 in the Connect State 7209 Status: Consensus 7210 Change: Yes 7211 Summary: Make event 14 optional. 7213 Discussion: 7215 Siva opened the discussion with: 7217 > If the transport connection receives an indication > that is 7218 invalid or unconfigured. [Event 14]: > - the TCP connection is 7219 rejected. 7221 I don't understand how we would get this event while in this state. 7223 Sue replied: 7225 See my earlier comments (1-10) on the connection state. It happens 7226 in implementations which track the TCP state more closely. I suggest 7227 that Event 14 become optional. 7229 Sue also suggested we fold this into the discussion about events 7230 13-17, which is tracked in issue 13.4. 7232 Sue proposed: 7234 My resolution: Let event 14 be optional. Not all BGP implementations 7235 support it. 7237 And asked if this let us reach consensus on this issue. 7239 Siva agreed with this, we are at consensus on this. 7241 This was discussed in the "Comments 21-30" thread: Comment #22. This 7242 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7244 3.42. Handling events 20, 21 in the Connect State and Active State 7246 Status: Consensus 7247 Change: Yes 7248 Summary: Use the text Tom proposed in the discussion section. 7250 Discussion: 7252 Siva began this with: 7254 We need to consider the case where we receive events 20 (message 7255 header error) and 21 (Open message error) when the delay timer is 7256 running. 7258 Since the connection has been established at this point, we need to 7259 send a Notification message and then terminate the connection. 7261 To which Sue replied: 7263 Alternative comments: 7265 1) We have not sent an Open statement. 2) Why do we have to send an 7266 Notification? I see no justification for it. 7268 Suggestion: Do you have implementations that send notification? Do 7269 you know of others that don't. 7271 Jeff saw this as indicative of an issue with section 4.2 the way it 7272 is currently written: 7274 >From section 4.2 of -18: .in 4 4.2 OPEN Message Format 7276 .in 7 After a TCP is established, the first message sent by each side 7277 is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE 7278 message confirming the OPEN is sent back. Once the OPEN is 7279 confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be 7280 exchanged. 7282 This text implies that NOTIFICATIONs can only be sent once we have 7283 sent an open and then a keepalive, generally meaning we're in the 7284 Established state. 7286 Anyone suggestions for modifying the wording? 7288 Section 6.1 (Message header error) is one situation that implies that 7289 a NOTIFICATION can be sent without sending even an OPEN message. 7290 Note that since the base FSM implies that we send an OPEN message 7291 immediately when we have a completed transport connection, we SHOULD 7292 be in at least OpenSent. However, the DelayOpen timer means that we 7293 MAY send a NOTIFICATION when we are in the Connect state. 7295 GateD, at least, will not send a NOTIFICATION without first sending 7296 an OPEN. 7298 We need to pick one: You can send NOTIFICATIONS before OPEN or before 7299 OPEN if the OpenDelay timer is running. However, we MUST fix the 7300 text above. 7302 Tom opined: 7304 .in 4 A NOTIFICATION without a preceding OPEN is rather hard to 7305 interpret; it is the OPEN that gives the recipient what it needs to 7306 know about its potential peer (Version, AS number, ID, options etc) 7307 so it makes sense to send an OPEN even if it is followed by a 7308 NOTIFICATION to say goodbye :-( as opposed to a KEEPALIVE which says 7309 hello:-). 7311 But as ever, what is implemented? 7313 Yakov suggested these modifications to the text to resolve this: 7315 .in 4 1. Delete the last sentence in the above paragraph 7317 or 7319 2. Delete "and NOTIFICATION" in the last sentence in the above 7320 paragraph 7322 Jeff replied that he preferred the first option, and that the second 7323 could be interpreted as NOTIFICATIONs not being legal, when, in fact, 7324 they may. 7326 So the text on the table to resolve this is: 7328 4.2 OPEN Message Format 7330 .in 7 After a TCP is established, the first message sent by each side 7331 is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE 7332 message confirming the OPEN is sent back. 7334 However, this does not entirely clear up the original point about the 7335 FSM. If we receive an error in Connect/Active, do we send a NOTIFY? 7336 Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in 7337 immediate succession? 7339 Sue replied: 7341 .in 4 I suggest we don't send a "NOTIFICATION" when Event 20 or Event 7342 21 is received in Connect or Active state. 7344 Tom responded to this issue with: 7346 .in 4 Issue 42 queries whether or not we can send a NOTIFICATION when 7347 we have not successfully exchanged OPENs. I propose we should, 7348 following the suggestions of Jeff and Yakov. 7350 As Yakov suggested, this requires the removal of the second sentence, 7351 first paragraph, of 4.2 which implies a NOTIFICATION can only be sent 7352 after a successful exchange of OPENs. I think this fits best with 7353 the other references to the uses of NOTIFICATION in the draft. 7355 In terms of the FSM, it means that in Connect and Active states, on 7356 receipt of events 20 or 21, we should send a NOTIFICATION so that the 7357 last section starting 7359 In response to any other event............. 7361 is replaced by (and noting we have agreed to drop references to MIB 7362 actions) 7364 If the BGP message header checking or OPEN message checking detect an 7365 error (see Section 6.2) [Events 20 or 21], the local system: - sends 7366 a NOTIFICATION message with the appropriate error code, - resets the 7367 connect retry timer (sets to zero), - releases all BGP resources, - 7368 drops the TCP connection - increments the ConnectRetryCnt (connect 7369 retry count) by 1, - [optionally] performs peer oscillation damping - 7370 and goes to the Idle state. In response to any other event (Events 7371 7-8, 10-11,18, 22-27), the local system: - resets the connect retry 7372 timer (sets to zero), - releases all BGP resources, - drops the TCP 7373 connection, - increments the ConnectRetryCnt (connect retry count) by 7374 one, - [optionally] performs peer oscillation damping, - and goes to 7375 the Idle state 7376 .in 4 (Note that this text is not quite watertight. Suppose we are 7377 in Active state, having been started with CRT running, receive an SYN 7378 (event 13), send SYN-ACK and then get a malformed message (events 7379 20/21). We have not yet received an ACK and so should not send 7380 anything over TCP; I would expect TCP to buffer this awaiting the ACK 7381 except we then take down the TCP connection - or try to; I don't know 7382 what happens next but regard it as sufficiently obscure not to be 7383 concerned). 7385 (My other concern is greater; why do we now not send NOTIFICATIONs 7386 for other events; in Open Sent, Open Confirm or Established, we send 7387 one for the 'default event list' so what makes events 20 and 21 in 7388 Active and Connect so special? I can justify the absence of a 7389 NOTIFICATION for events 7, 8, 10, 11, 18, 22 since there is no 7390 evidence of a TCP connection to send it on; but events 23-27 in 7391 Active or Connect say we have received an erroneous message, the TCP 7392 connection is there so why not send a NOTIFICATION? Event7: 7393 Automatic stop Event8: Idle hold timer expires Event10: Hold timer 7394 expires Event11: Keepalive timer expires Event18: BGPOpen Event22: 7395 Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg 7396 Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr 7398 Sue accepted Tom's text, so barring any objections, we are at 7399 consensus on this. 7401 This was discussed in the "Comments 21-30" thread: Comment #23. This 7402 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and 7403 the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread. 7405 3.43. Handling the default events in the Connect state 7407 Status: No Consensus 7408 Change: Potentially 7409 Summary: Add text at the end of the discussion. 7411 Discussion: 7413 Siva opened this with: 7415 .in 4 The Open Delay timer [original: BGP Delay Open Timers) needs to 7416 be cleared if it is running. 7418 How about adding this: 7420 % - If the ConnectRetry Timer is running % - Clear the Connect Retry 7421 timer % - Otherwise % - Clear the Open Delay timer [original: BGP 7422 Delay Open Timer] 7423 Sue replied that: 7425 By the default you mean the text: 7427 In response to any other events[Events 7-8, 10-11, 18, 20-27], the 7428 local system: 7430 "resets" to me implies stops and clears. I think the text is clear 7431 than the text above. ------------ Is this the replacement text you 7432 imply above: - resets the connect retry timer (sets to zero), - 7433 clears the Open Delay timer [original: BGP Delay timer] (sets to 7434 zero), - increments the ConnectRetryCnt (connect retry count) by 1, - 7435 [optionally] performs bgp peer oscillation damping, and - goes to 7436 Idle text: 7438 Editor's note: various incarnations of "Open Delay timer" have been 7439 replaced with "Open Delay timer". See issue 7. 7441 Sue replied that she accepted Siva's changes with these editorial 7442 changes: 7444 old text: - resets the connect retry timer (sets to zero) - clears 7445 the open delay timer 7447 new text: - if the connect retry timer is running, clear the connect 7448 retry timer (set to zero). - if the open delay timer is running, 7449 clear the open delay timer (set to zero). 7451 Since the substantive changes have been accepted, unless someone 7452 objects, this issue is at consensus. 7454 This was discussed in the "Comments 21-30" thread: Comment #24. This 7455 was also brought up in the "BGP-19: Issue 34-35, 40-48" 7457 3.44. Handling Event 23 in Connect and OpenSent 7459 Status: Consensus 7460 Change: Yes 7461 Summary: Adopt text at the end of the discussion section. 7463 Discussion: 7465 This began with Siva saying: 7467 .in 4 This is currently being handled in the default event processing 7468 section. However, we do not need to go through the peer oscillation 7469 damping process in this case. Can we change the wordings to reflect 7470 this, or move this out of peer oscillation damping processing ? 7471 Sue replied: 7473 1) There is no default event handling process in the text, you will 7474 need to specify the text. 7476 2) The state table below (hares-statemt-03.txt) states shows the 7477 changes 7479 ------------- 7480 Event 23 7481 states: 7482 current Idle Connect Active Open-Sent Open-Cnf Establish 7483 ------------------------------------------------- 7484 next state Idle Idle Idle Idle Idle Idle 7485 ------------------------------------------------- 7486 action V D D Y Y T ================================================= 7488 V - Indicate FSM errors and ignore. D - 1) resets the connect retry 7489 timer (sets to zero), 2) drops the TCP connection, 2) releases all 7490 BGP resources, 3) increments the ConnectRetryCnt (connect retry 7491 count) by 1, 4) [optionally] performs the bgp peer oscillation 7492 damping, and Goes to Idle state. Y 1) resets the connect retry timer 7493 (sets to zero), 2) Drops the TCP connection, 3) releases all BGP 7494 resources, 4) [optionally] 7496 In an exchange between Siva and Sue, this came up: 7498 Siva: 7500 "Default event handling" was perhaps a poor choice of words. 7502 What I meant is this 7504 .in 4 Event 23 (Notify Message Version error) only indicates a 7505 version mismatch. By going through action sequence D, we will be 7506 performing peer oscillation damping. Should we perform damping, 7507 since this is not really a cause for persistent oscillation ? 7509 Also, since we have a distinct event to indicate a version error 7510 event, can include text indicating that version negotiation 7511 processing should take place upon receipt of this event ? 7513 Sue: 7515 Yes, we can change the "D" in state machine to a "y". 7517 The issue is what if Connect state occurs and there is not a TCP 7518 connection. Should an OPEN with wrong version be accepted? If the 7519 Open Delay flag is off, the connection state should not be getting an 7520 Open. The "D" action below works for "open delay flag off". 7522 The "y" action you suggest can occur if the open delay timer is on. 7524 If this is the issue, please confirm. 7526 We could say: if open delay flag is on -> y action if open delay flag 7527 is off -> D action 7529 Please let me know if this is the concern, and suggest text. 7531 Prior to this exchange, this issue was at consensus. The only thing 7532 that is firm in this exchange is changing "D" to "y". There seems to 7533 be some open discussion still, so we'll reopen it. 7535 After some discussion, this is the text we have settled on: 7537 If a NOTIFICATION message is received with a version error[Event24], 7538 the local system checks the Open Delay timer. If the Open Delay 7539 timer is running, the local system: - resets the connect retry timer 7540 (sets to zero), - stops and reset the Open Delay timer (sets to zero, 7541 - releases all BGP resources, - drops the TCP connection, - changes 7542 its state to Idle. If the Open Delay timer is not running, the local 7543 system: - resets the connect retry timer (sets to zero), - releases 7544 all BGP resources, - drops the TCP connection, - increments the 7545 ConnectRetryCnt (connect retry count) by 1, - optionally performs 7546 peer oscillation damping, and - changes its state to Idle. 7548 N.B. This is now event 24 (see issue 26). 7550 We are at consensus with this. 7552 This was discussed in the "Comments 21-30" thread: Comment #25. This 7553 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7555 3.45. Event 17 in the Connect state 7557 Status: Consensus 7558 Change: Yes 7559 Summary: Adopt text at the end of the discussion section. 7561 Discussion: 7563 This began with Siva asking: 7565 .in 4 If the transport connection fails (timeout or transport 7566 disconnect) [Event17], the local system: - changes its state to 7567 Active. 7569 If the transport connection fails when the Open Delay timer 7570 [original: BGP Open Delay timer] is running, should we still be going 7571 into the Active state ? 7573 Sue replied referring to the discussion tracked in issue 13.4. 7575 Jeff responded that: 7577 .in 4 In this particular case, I think the issue is separate from the 7578 issues for events 13-17 since this isn't particular to how deep the 7579 BGP implementation meddles in the TCP implementation. 7581 If we are in the Connect state, because we have an incoming transport 7582 connection that has completed, but we have the OpenDelay timer 7583 running and the transport connection is closed, we can simply drop 7584 into Active after resetting the ConnectRetry timer and clearing the 7585 OpenDelay timer (if set/exists). In the case of an unconfigured 7586 peer, we can discard the FSM instance. 7588 Tom replied that he agreed with this. 7590 Tom then proposed this text: 7592 If the TCP connection fails[Event 17] and the Open Delay timer is 7593 running, the local system: - restarts the connect retry timer, - 7594 clears the Open Delay timer - continues to listen for a connection 7595 that may be initiated by the remote BGP peer, and - changes its state 7596 to Active. 7598 If the TCP connection fails [Event17] and the Open Delay timer is not 7599 running, the local system: - drops the TCP connection, - releases all 7600 BGP resources, - sets ConnectRetryCnt (the connect retry count) to 7601 zero - resets the connect retry timer (sets to zero), and - goes to 7602 Idle state. 7604 to replace If the TCP connection fails (timeout or disconnect) 7605 [Event17], the local system: - restarts the connect retry timer, - 7606 continues to listen for a connection that may be initiated by the 7607 remote BGP peer, and - changes its state to Active. 7609 Sue agreed to change the text to reflect the comments. 7611 Jeff brought out a couple of other concerns, and Tom replied: 7613 > If the TCP connection fails [Event17] and the Open Delay > timer is 7614 not running, the local system: > - drops the TCP connection, > - 7615 releases all BGP resources, 7617 .in 4 There are no resources to release while in the connect state. 7618 (Unless we're using this as shorthand for something else - I forget.) 7620 Tom: 7622 .in 4 I was unsure about this action. It is present for Active state 7623 event 17 which is why I put it in, it does include sub-actions such 7624 as clear Open Delay timer (not running), clear Connect Retry timer 7625 (could be running) so I think it right to play safe and include it. 7627 Jeff: 7629 > - sets ConnectRetryCnt (the connect retry count) to zero 7631 I'm forgetting if this action is consistent with everything else. I 7632 don't have a current copy of the FSM and I don't trust -18 to be 7633 current enough. :-) This said, why do we go to zero? I could see not 7634 incrementing it and letting the normal decay process deal with it. 7635 The same would apply for the above. 7637 Tom: 7639 .in 4 Again, I was unsure about this so put it in and waited for 7640 comment. I have a chart of 27 events and 6 states in which I have 7641 colored in the connect retry and peer oscillation damping actions and 7642 it looks like measles; I could not divine the underlying logic. 7643 Incrementing the connect retry count would make as much if not more 7644 sense to me. (It is zeroed for Manual Stop). 7646 But the action '[optionally] perform peer oscillation damping' is yet 7647 more erratic (eg for event 10 - Hold Timer expired - it is performed 7648 exiting Connect, Active, Established but not Open Confirm or Open 7649 Sent) so I left it out. Again, it might make more sense put it in. 7651 Sue replied to this: 7653 The connect state could have a few resources (minimum peer footprint) 7654 as the FSM goes from Idle to Connected state. While this amount of 7655 BGP resources is not as much as the final amount, it still needs to 7656 get released. 7658 2nd - I think the ConnectRetry count should be removed; Thanks for 7659 catching that. 7661 Please confirm that part #1 is OK with you so we can put issue 45 7662 into consensus state. 7664 Sue accepted Tom's solution, for the following text: 7666 If the TCP connection fails [Event18], the local system checks the 7667 Open Delay Timer. If the Open Delay timer is running, the local 7668 system: - restarts the connect retry timer, - stops the Open Delay 7669 timer and resets value to zero, - continues to listen for a 7670 connection that may be initiated by the remote BGP peer, and - 7671 changes its state to Active. If the open Delay timer is not running, 7672 the local system: - resets the connect retry timer (sets to zero), 7673 and - Drops the TCP connection, - Releases all BGP resources, - and 7674 goes to Idle State. 7676 N.B. This is now event 18 (see issue 26). 7678 We are at consensus with this. 7680 This was discussed in the "Comments 21-30" thread: Comment #26. This 7681 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7683 3.46. Handling of Event 17 in Active state 7685 Status: Consensus 7686 Change: No 7687 Summary: See issue 13.4, this issue closed in favor of that one. 7689 Discussion: 7691 This began with Siva saying: 7693 We should now move into Idle state. Can we add 7695 % - Goes to Idle state 7697 Sue replied that she thought this should be bundled in with the issue 7698 tracked in 13.4. Since no one objected, this issue has been closed 7699 in favor of that one. 7701 This was discussed in the "Comments 21-30" thread: Comment #27. 7703 3.47. Handling of Event 19 in Active state 7705 Status: Consensus 7706 Change: Yes 7707 Summary: Add the new text in the discussion section. 7709 Discussion: 7711 This began with Siva suggesting: 7713 > - Set the Hold timer to a large value (4 minutes), Since OPEN 7714 messages have been exchanged, can we change this to - If the 7715 negotiated Hold time is not 0, set the Hold time to - the negotiated 7716 value 7718 Sue replied that: 7720 The text in Active and Open Sent needs to be the same. The text in 7721 Open Sent is: - sets the Hold timer according to the negotiated value 7722 (see section 4.2), and 7724 Which text do you prefer? 7726 Sue replied that this text would be added to the next draft: 7728 New text 7730 - if the hold timer value is non-zero, - starts the keepalive timer 7731 to initial value, - resets the hold timer to the negotiated value, - 7732 else if the hold timer is zero - resets the keepalive timer (set to 7733 zero), - resets the hold timer to zero. 7735 This seems to address Siva's concerns, this issue is at consensus, if 7736 there are objections, we can reopen it. 7738 This was discussed in the "Comments 21-30" thread: Comment #28. This 7739 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7741 3.48. Handling of Event 2 in Active state 7743 Status: Consensus 7744 Change: Yes 7745 Summary: Update the draft with the text at the end of the discussion 7746 section. 7748 Discussion: 7750 Siva opened with: 7752 > A manual stop event[Event2], the local system: > - Sends a 7753 notification with a Cease, > - drops the Transport connection 7755 These two actions are possible only if a transport connection had 7756 already been established. How about changing the text to 7758 % - If a transport connection had been successfully established % - 7759 Send a Notification with a Cease % - Drop the Transport Connection 7760 Sue counter suggested: 7762 A manual stop event [Event 2], the local system - Drop the TCP 7763 connection, - Release all BGP resources, - resets the connection 7764 retry timer [sets to zero], - goes to Idle. 7766 Jeff replied: 7768 I'm rather confused. Under exactly what circumstances can we be in 7769 the Active state and have an active TCP connection at all? Ditto for 7770 having any BGP resources? 7772 Going to Idle is fine. 7774 Tom offered this example: 7776 eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK 7777 received, Delay Open flag set and there we are. Most events are now 7778 possible either from a well-implemented remote peer or a badly 7779 implemented remote peer. 7781 Sue asked if there were any additional comments, if not, the text 7782 will be: 7784 A manual stop event[Event2], the local system: - Sends a NOTIFICATION 7785 with a Cease, - releases all BGP resources including - stopping the 7786 Open delay timer - drops the TCP connection, - sets ConnectRetryCnt 7787 (connect retry count) to zero - resets the connect retry timer (sets 7788 to zero), - changes its state to Idle. 7790 There have been no additional comments, we will use the text Sue 7791 proposed. 7793 This was discussed in the "Comments 21-30" thread: Comment #29. This 7794 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7796 3.49. Default Event handling in Active state 7798 Status: Consensus 7799 Change: No 7800 Summary: No routes in active. 7802 Discussion: 7804 Siva began with: 7806 To ensure consistency with E2 handling, can we add 7807 % - If any BGP Routes exist, delete the routes 7809 Sue replied: 7811 Comment: Yakov and Jeff noted, there are no routes in Active state. 7813 Since there were no responses disagreeing, we'll consider this closed 7814 unless someone wants to open it back up. 7816 This was discussed in the "Comments 21-30" thread: Comment #30. 7818 3.50. Clearing Hold timer in OpenSent, OpenConfirm and Established 7819 State 7821 Status: Consensus 7822 Change: No 7823 Summary: This issue is addressed in the "Clear BGP resources" 7825 Discussion: 7827 This began with Siva stating: 7829 .in 4 In all event handling where we go to Idle state, we need to 7830 clear the Hold Timer as well. 7832 Sue replied that: 7834 issue resolve one way last Jan - March Clearing of keep alive timer 7835 included in Clear BGP resources 7837 No response to this yet, but since this seems to be resolved it is at 7838 consensus unless someone objects. 7840 This was discussed in the "Comments 30-36" thread: Comment #31. 7842 3.51. Clearing Keepalive timer in OpenConfirm and Established State 7844 Status: Consensus 7845 Change: No 7846 Summary: This issue is addressed in the "Clear BGP resources" 7848 Discussion: 7850 This began with Siva stating: 7852 .in 4 In all event handling where we go to Idle state, we need to 7853 clear the Keepalive Timer as well. 7855 Sue replied that: 7857 issue resolve one way last Jan - March Clearing of keep alive timer 7858 included in Clear BGP resources 7860 No response to this yet, but since this seems to be resolved it is at 7861 consensus unless someone objects. 7863 This was discussed in the "Comments 30-36" thread: Comment #32. 7865 3.52. Handling Event 18 in the OpenSent state (Keepalive Timer) 7867 Status: Consensus 7868 Change: Yes 7869 Summary: Make the event optional. 7871 Discussion: 7873 This began with Siva asking: 7875 .in 4 Why do we start the Keepalive timer at this stage ? Isn't it 7876 sufficient to do so when we move into Established state ? 7878 Sue replied: 7880 An earlier comment from Tom (and you) requested the following: 7882 <--Open [Open sent state] 7884 Open--> [Event 18] 7886 <---Open <---Keepalive [Action from Event 18 in Open Sent] [Open 7887 Confirm] Keepalive -> [Event 25] [established] 7889 What do implementations do? We'll have to query implementations. 7891 Jeff added: 7893 I'm assuming the second OPEN going from right to left is a typo. If 7894 it isn't, thats a FSM error to the peer on the left. 7896 Theoretically, an implementation that utilizes its keepalive timer to 7897 send the first keepalive to transition to Established is still 7898 interoperable. However: 7900 o Keepalives can be disabled by negotiating hold time of zero o We 7901 really shouldn't need to restart the Keepalive timer. If there is a 7902 delay in the keepalive that transitions from OpenConfirm to 7903 Established, its due to the transport connection. It should be 7904 reliable and it *should* get through. If it doesn't, there's other 7905 problems and the hold timer for the peer on the right should do the 7906 Right Thing and drop the connection. 7908 > What do implementations do? We'll have to query implementations. 7910 .in 4 GateD at least waits to enter the Established state prior to 7911 starting the KeepAlive timer. 7913 Tom also added: 7915 .in 4 My comment was that if we do not send a KeepAlive (and start 7916 the KeepAlive timer), on exiting from Active with Event 19 to 7917 OpenConfirm then we never will and the connection will die. Open 7918 Confirm state means valid Open received so we must send a KeepAlive 7919 to acknowledge the Open (as pointed out in Jeff's other posting) and 7920 we never do it in OpenConfirm state itself (unless the KeepAlive 7921 timer expires which it cannot because we have not started it). 7923 So for me, OpenSent state Event 18 was and is correct, sending the 7924 KeepAlive without which the connection goes no further and Active 7925 state Event 19 needs to be brought into line. 7927 To say that the timer is started when entering Established state is 7928 fine except for a slight problem; we have no way in this FSM of 7929 defining actions that are taken on entering a state, only actions to 7930 be taken on leaving another state so that is why the KeepAlive 7931 actions need to be where they are (or are not in the case of Active 7932 state Event 19). 7934 Sue replied, asking more implementors to chime in on what they do for 7935 this part of the FSM. 7937 Curtis replied that we should: 7939 .in 4 Make it optional. Timing out in open or open-sent has never 7940 been much of an issue, so whether one or three keepalive get sent 7941 shouldn't be a hot topic. 7943 Sue said that this was fine, and she would work on text specifying 7944 optional. 7946 Jeff replied regarding GateD's behavior: 7948 .in 4 GateD will start its keepalive timer while in this state, so 7949 multiple keepalives will be sent. 7951 As someone previously said, this is a "yawn" issue. But to choose 7952 one way or the other, we may potentially make someone in non- 7953 compliance. 7955 From the closure of issue 12, we have this text, which discusses 7956 Keepalives to consider in relation to the other keepalive issue here: 7958 Change 1: new text 7960 Active state - event 19 7962 If an Open is received with the Open Delay timer is running [Event 7963 19], the local system - clears the connect retry timer (cleared to 7964 zero), - stops and clears the Open Delay timer - completes the BGP 7965 initialization, - stops and clears the Open Delay timer - sends an 7966 OPEN message, - send a Keepalive message, - if the hold timer value 7967 is non-zero, - starts the keepalive timer to initial value, - resets 7968 the hold timer to the negotiated value, else if the hold timer is 7969 zero - resets the keepalive timer (set to zero), - resets the hold 7970 timer to zero. 7972 - changes its state to OpenConfirm. 7974 .in 7 If the value of the autonomous system field is the same as the 7975 local Autonomous System number, set the connection status to an 7976 internal connection; otherwise it is "external". 7978 Since there were no more comments, this is at consensus. 7980 This was discussed in the "Comments 30-36" thread: Comment #33. And 7981 in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State 7982 (Keepalive timer set)" thread. 7984 3.53. Established State MIB 7986 Status: Consensus 7987 Change: No 7988 Summary: MIB references pulled in favor of having them in the MIB 7989 document. See issue 8. 7991 Discussion: 7993 This began with Siva asking: 7995 .in 4 Some event handling in the Established state do not set the MIB 7996 Reason when handling an event that causes an error. Can we add this 7997 ? 7998 Sue replied that we have pulled the MIB wording from the FSM. See 7999 issue 8. 8001 This was discussed in the "Comments 30-36" thread: Comment #34. 8003 3.54. State impact of not supporting Optional Events 8005 Status: Consensus 8006 Change: Yes 8007 Summary: Add the text at the end of the discussion section. 8009 Discussion: 8011 Siva stated that: 8013 .in 4 For the events whose status is optional, can we state the 8014 impact of not supporting them (in terms of any interoperability 8015 issues). I understand that most of the optional events will not have 8016 such an impact; but a clarification statement for the optional events 8017 would benefit new implementors. 8019 Sue responded: 8021 Much of the support of optional parameters depends on policy. I 8022 could put a short note about the optional events and parameters as 8023 part of 8.1.5 or 8.2.1.3 8025 I think it fits better in 8.1.5. Optional: Events: 3-8, 12, 13-14[my 8026 suggestion] 19, 22 Timers: Idle Hold Timer Open Delay Timer 8028 Required flags for optional parameters: Open Delay Flag BGP Stop Flap 8030 Sue said she would try to work up more if it is agreed that this is 8031 on the right track. 8033 Sue provided this text to clarify the behavior associated with 8034 Optional Attributes: 8036 8.2.1.3 FSM and Optional Attributes 8038 Optional Attributes specify either flags that augment the normal 8039 processing of the BGP FSM, or optional timers. If a Optional 8040 attribute can be set on a system, the Events and the BGP FSM actions 8041 must be support. For example, if the following options can be set in 8042 a BGP implementation: AutoStart and Passive TCP connection 8043 Establishment flag, then the events 3, 4 and 5 must be supported. 8045 If an Optional attribute cannot be set (that is declared always off 8046 logically), the events supporting that set of options do not have to 8047 be supported. 8049 This was discussed in the "Comments 30-36" thread: Comment #35. 8051 3.55. New DelayOpen State 8053 Status: Consensus 8054 Change: No 8055 Summary: We've chosen not to reopen the debate about adding a 8056 DelayOpen State to the FSM. 8058 Discussion: 8060 Siva began with asking: 8062 .in 4 Is delaying the sending of an OPEN message a standard industry 8063 practice ? 8065 Also, in the FSM, this has been handled by practically implementing a 8066 sub-state each, within the CONNECT and ACTIVE states. Won't the FSM 8067 look more simple if we just had a new DelayOpen state that we could 8068 move into ? 8070 Sue responded that this was something we have tried to do before, but 8071 that it spawned some degree of rabid response on both sides. Given 8072 our current mandate to stick with what is implemented, it is probably 8073 best not to reopen this debate. 8075 Unless someone badly wants to reopen this debate, the issue is at 8076 Consensus. 8078 This was discussed in the "Comments 21-30" thread: Comment #22. 8079 This was discussed in the "Comments 21-30" thread: Comment #26. 8080 This was discussed in the "Comments 30-36" thread: Comment #36. 8082 3.56. Clarify what is covered in the base document 8084 Status: Consensus 8085 Change: Yes 8086 Summary: Add the text at the end of the discussion to clarify what is 8087 documented where with regard to BGP and its extensions. 8089 Discussion: 8091 This grew out of a discussion on how to use BGP Identifiers in an 8092 IPv6-only environment. In that discussion it became clear that the 8093 way the documents are currently structured it is not clear to new 8094 readers that extension specifications can and do specify behavior 8095 that supersedes the behavior specified in the base spec. To that end 8096 it was agreed that this text should be added: 8098 .in 5 This document specifies the base behavior of the BGP protocol. 8099 This behavior can and is modified by extension specifications. When 8100 the protocol is extended the new behavior is fully documented in the 8101 extension specifications. 8103 This was discussed in the "Next-Hop in IPv6 only environments" 8104 thread. 8106 4. Security Considerations 8108 This document is an informational document that discusses the changes 8109 made in revising the BGP-4 specification. There are no security 8110 considerations applicable to this document. 8112 5. IANA Considerations 8114 This document has no considerations for IANA. 8116 6. References 8118 6.1. Normative References 8120 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 8121 (BGP-4)", RFC 1771, March 1995. 8123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 8124 Requirement Levels", BCP 14, RFC 2119, March 1997. 8126 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 8127 Protocol 4 (BGP-4)", RFC 4271, January 2006. 8129 6.2. Informative References 8131 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 8132 Signature Option", RFC 2385, August 1998. 8134 [RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement 8135 with BGP-4", RFC 2842, May 2000. 8137 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 8138 September 2000. 8140 [RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 8141 System Confederations for BGP", RFC 3065, February 2001. 8143 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 8144 with BGP-4", RFC 3392, November 2002. 8146 [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental 8147 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 8149 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 8150 Authentication Option", RFC 5925, June 2010. 8152 Author's Address 8154 Andrew S. Lange 8155 Alcatel-Lucent 8157 Email: andrew.lange@alcatel-lucent.com