idnits 2.17.1 draft-ietf-idr-bgp-issues-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 509: '...mentation of BGP MUST allow the Hold T...' RFC 2119 keyword, line 510: '...onfigurable, and MAY allow the other t...' RFC 2119 keyword, line 554: '...tter random value MAY be configurable....' RFC 2119 keyword, line 589: '...mentation of BGP MUST allow the Hold T...' RFC 2119 keyword, line 590: '...onfigurable, and MAY allow the other t...' (107 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If due to the limits on the maximum size of an UPDATE message (see Section 4) a single route doesn't fit into the message, the BGP speaker MUST not advertise the route to its peers and may choose to log an error locally. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If due to the limits on the maximum size of an UPDATE message (see Section 4) a single route doesn't fit into the message, the BGP speaker MUST not advertise the route to its peers and may choose to log an error locally. -- 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 (August 17, 2010) is 4993 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 934, but not defined == Missing Reference: 'RWStevens' is mentioned on line 1305, but not defined == Missing Reference: 'RFC2385' is mentioned on line 4088, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Missing Reference: 'RFC2918' is mentioned on line 1701, but not defined == Missing Reference: 'RFC2842' is mentioned on line 1731, but not defined ** Obsolete undefined reference: RFC 2842 (Obsoleted by RFC 3392) -- Looks like a reference, but probably isn't: '1' on line 1836 == Missing Reference: 'RFC904' is mentioned on line 6119, but not defined -- Looks like a reference, but probably isn't: '12' on line 3037 -- Looks like a reference, but probably isn't: '10' on line 4077 == Missing Reference: 'RFC793' is mentioned on line 4085, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) -- Looks like a reference, but probably isn't: '13' on line 4640 == Missing Reference: 'Event 9' is mentioned on line 5205, but not defined == Missing Reference: 'Event17' is mentioned on line 7607, but not defined == Missing Reference: 'Event 18' is mentioned on line 7878, but not defined == Missing Reference: 'Event 19' is mentioned on line 5055, but not defined == Missing Reference: 'Event 14' is mentioned on line 7212, but not defined == Missing Reference: 'Event 13' is mentioned on line 5797, but not defined == Missing Reference: 'Event 17' is mentioned on line 7586, but not defined == Missing Reference: 'Event 22' is mentioned on line 5806, but not defined == Missing Reference: 'Event 15' is mentioned on line 5798, but not defined == Missing Reference: 'RFC3065' is mentioned on line 5959, but not defined ** Obsolete undefined reference: RFC 3065 (Obsoleted by RFC 5065) == Missing Reference: 'Event 1' is mentioned on line 6670, but not defined == Missing Reference: '3-6' is mentioned on line 6676, but not defined == Missing Reference: 'Event1' is mentioned on line 6676, but not defined == Missing Reference: 'Events 7-8' is mentioned on line 7421, but not defined == Missing Reference: '10-11' is mentioned on line 7421, but not defined -- Looks like a reference, but probably isn't: '18' on line 7421 == Missing Reference: '20-27' is mentioned on line 7421, but not defined == Missing Reference: 'Event24' is mentioned on line 7531, but not defined == Missing Reference: 'Event18' is mentioned on line 7660, but not defined == Missing Reference: 'Event2' is mentioned on line 7778, but not defined == Missing Reference: 'Event 2' is mentioned on line 7756, but not defined == Missing Reference: 'Event 25' is mentioned on line 7881, but not defined == Unused Reference: 'RFC1771' is defined on line 8108, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) Summary: 7 errors (**), 0 flaws (~~), 33 warnings (==), 8 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 August 17, 2010 5 Expires: February 18, 2011 7 Issues in Revising BGP-4 (RFC1771 to RFC4271) 8 draft-ietf-idr-bgp-issues-03 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 results of these efforts are 16 encoded in RFC4271. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 18, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 53 2. The Issues from -17 to -18 . . . . . . . . . . . . . . . . . 6 54 2.1. IDR WG Charter . . . . . . . . . . . . . . . . . . . . . 6 55 2.2. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2.3. FSM wording for what state BGP accepts connections in . . 8 57 2.4. BGP Identifier/Router ID . . . . . . . . . . . . . . . . 8 58 2.5. Direct EBGP Peers . . . . . . . . . . . . . . . . . . . . 8 59 2.6. Disallow Private Addresses . . . . . . . . . . . . . . . 9 60 2.7. Renumber Appendix Sections . . . . . . . . . . . . . . . 9 61 2.8. Jitter Text . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.9. Reference to RFC904 - EGP Protocol . . . . . . . . . . . 14 63 2.10. Extending AS_PATH Attribute . . . . . . . . . . . . . . . 14 64 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 65 9.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 2.11.1. Rules for routes from Loc-RIB to Adj-RIB-Out - 67 Section 9.1.3 . . . . . . . . . . . . . . . . . . . 18 68 2.11.2. Rules for routes from Loc-RIB to Adj-RIB-Out - 69 Section 2 . . . . . . . . . . . . . . . . . . . . . 19 70 2.11.3. Documenting IBGP Multipath . . . . . . . . . . . . . 21 71 2.12. TCP Behavior Wording . . . . . . . . . . . . . . . . . . 25 72 2.13. Next Hop for Originated Route . . . . . . . . . . . . . . 25 73 2.14. NEXT_HOP to Internal Peer . . . . . . . . . . . . . . . . 26 74 2.15. Grammar Fix . . . . . . . . . . . . . . . . . . . . . . . 26 75 2.16. Need ToC, Glossary and Index . . . . . . . . . . . . . . 27 76 2.17. Add References to other RFC-status BGP docs to base 77 spec . . . . . . . . . . . . . . . . . . . . . . . . . . 27 78 2.18. IP Layer Fragmentation . . . . . . . . . . . . . . . . . 27 79 2.19. Appendix Section 6.2: Processing Messages on a Stream 80 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 28 81 2.20. Wording fix in Section 4.3 . . . . . . . . . . . . . . . 29 82 2.21. Authentication Text Update . . . . . . . . . . . . . . . 29 83 2.22. Scope of Path Attribute Field . . . . . . . . . . . . . . 30 84 2.23. Withdrawn and Updated routes in the same UPDATE message . 31 85 2.24. Addition or Deletion of Path Attributes . . . . . . . . . 32 86 2.25. NEXT_HOP Semantics . . . . . . . . . . . . . . . . . . . 33 87 2.26. Attributes with Multiple Prefixes . . . . . . . . . . . . 34 88 2.27. Allow All Non-Destructive Messages to Refresh Hold 89 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . 34 90 2.28. BGP Identifier as Variable Quantity . . . . . . . . . . . 35 91 2.29. State Why Unresolveable Routes Should Be Kept in 92 Adj-RIB-In . . . . . . . . . . . . . . . . . . . . . . . 35 93 2.30. Mention Other Message Types . . . . . . . . . . . . . . . 36 94 2.31. Add References to Additional Options . . . . . . . . . . 37 95 2.32. Clarify EGP Reference . . . . . . . . . . . . . . . . . . 37 96 2.32.1. EGP ORIGIN Clarification . . . . . . . . . . . . . . 38 97 2.32.2. BGP Destination-based Forwarding Paradigm . . . . . 42 99 2.33. Add "Optional Non-Transitive" to the MED Section . . . . 46 100 2.34. Timer & Counter Definition . . . . . . . . . . . . . . . 46 101 2.35. Fix Typo . . . . . . . . . . . . . . . . . . . . . . . . 47 102 2.36. Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary . 47 103 2.37. Combine "Unfeasible Routes" and "Withdrawn Routes" . . . 47 104 2.38. Clarify Outbound Route Text . . . . . . . . . . . . . . . 49 105 2.39. Redundant Sentence Fragments . . . . . . . . . . . . . . 50 106 2.40. Section 9.2.1.1 - Per Peer vs. Per Router 107 MinRouteAdvertisementInterval . . . . . . . . . . . . . . 51 108 2.41. Mention FSM Internal Timers . . . . . . . . . . . . . . . 51 109 2.42. Delete the FSM Section . . . . . . . . . . . . . . . . . 52 110 2.43. Clarify the NOTIFICATION Section . . . . . . . . . . . . 52 111 2.44. Section 6.2: OPEN message error handling . . . . . . . . 53 112 2.45. Consistent References to BGP Peers/Connections/Sessions . 55 113 2.46. FSM Connection Collision Detection . . . . . . . . . . . 56 114 2.47. FSM - Add Explicit State Change Wording . . . . . . . . . 58 115 2.48. Explicitly Define Processing of Incoming Connections . . 58 116 2.49. Explicitly Define Event Generation . . . . . . . . . . . 62 117 2.50. FSM Timers . . . . . . . . . . . . . . . . . . . . . . . 63 118 2.51. FSM ConnectRetryCnt . . . . . . . . . . . . . . . . . . . 63 119 2.52. Section 3: Keeping routes in Adj-RIB-In . . . . . . . . . 64 120 2.53. Section 4.3 - Routes v. Destinations - Advertise . . . . 65 121 2.54. Section 4.3 - Routes v. Destinations - Withdraw . . . . . 66 122 2.55. Section 4.3 - Description of AS_PATH length . . . . . . . 68 123 2.56. Section 6 - BGP Error Handling . . . . . . . . . . . . . 69 124 2.57. Section 6.2 - Hold timer as Zero . . . . . . . . . . . . 71 125 2.58. Deprecation of ATOMIC_AGGREGATE . . . . . . . . . . . . . 72 126 2.59. Section 4.3 - Move text . . . . . . . . . . . . . . . . . 80 127 2.60. Section 4.3 - Path Attributes . . . . . . . . . . . . . . 81 128 2.61. Next Hop for Redistributed Routes . . . . . . . . . . . . 82 129 2.62. Deprecate BGP Authentication Optional Parameter from 130 RFC1771 . . . . . . . . . . . . . . . . . . . . . . . . . 84 131 2.63. Clarify MED Removal Text . . . . . . . . . . . . . . . . 88 132 2.64. MED for Originated Routes . . . . . . . . . . . . . . . . 93 133 2.65. Rules for Aggregating with MED and NEXT_HOP . . . . . . . 94 134 2.66. Complex AS Path Aggregating . . . . . . . . . . . . . . . 95 135 2.67. Counting AS_SET/AS_CONFED_* . . . . . . . . . . . . . . . 97 136 2.68. Outbound Loop Detection . . . . . . . . . . . . . . . . . 98 137 2.69. Appendix A - Other Documents . . . . . . . . . . . . . . 99 138 3. The Issues from -18 to -19 . . . . . . . . . . . . . . . . . 100 139 3.1. Reference to RFC 1772 . . . . . . . . . . . . . . . . . . 100 140 3.2. MUST/SHOULD Capitalization . . . . . . . . . . . . . . . 100 141 3.3. Fix Update Error Subcode 7 -- accidently removed . . . . 101 142 3.4. Section 5.1.4 - Editorial Comment . . . . . . . . . . . . 101 143 3.5. Section 9.1 - Change "all peers" to "peers" . . . . . . . 102 144 3.6. AS Loop Detection & Implicit Withdraws . . . . . . . . . 102 145 3.7. Standardize FSM Timer Descriptions . . . . . . . . . . . 103 146 3.8. FSM MIB enumerations . . . . . . . . . . . . . . . . . . 104 147 3.9. Make "delete routes" language consistent . . . . . . . . 104 148 3.10. Correct OpenSent and OpenConfirm delete wording . . . . . 105 149 3.11. Incorrect next state when the delay open timer expires . 105 150 3.12. Entering OpenConfirm / Adding "Stop OpenDelay" action . . 106 151 3.13. FSM Missing Next States . . . . . . . . . . . . . . . . . 110 152 3.13.1. FSM Missing Next States - Event 15 or 16 (Connect 153 State) . . . . . . . . . . . . . . . . . . . . . . . 111 154 3.13.2. FSM Missing Next States - Event 14 (Connect State) . 112 155 3.13.3. FSM Missing Next States - Event 15 or 16 (Active 156 State) . . . . . . . . . . . . . . . . . . . . . . . 114 157 3.13.4. FSM Missing Next States - Event 13-17 (TCP 158 Connection) . . . . . . . . . . . . . . . . . . . . 114 159 3.13.5. FSM Missing Next States - Event 17 (Connect State) . 116 160 3.13.6. FSM Missing Next States - Event 18 (Open Confirm) . 118 161 3.14. FSM - Peer Oscillation Damping . . . . . . . . . . . . . 120 162 3.15. FSM - Consistent FSM Event Names . . . . . . . . . . . . 121 163 3.16. Many Editorial Comments . . . . . . . . . . . . . . . . . 123 164 3.17. Section 3, Page 8, Paragraph 3 - Obsolete? . . . . . . . 127 165 3.18. MED Removal Text . . . . . . . . . . . . . . . . . . . . 130 166 3.19. Security Considerations . . . . . . . . . . . . . . . . . 133 167 3.20. Peer Oscillation Damping . . . . . . . . . . . . . . . . 133 168 3.21. Session Attributes - IdleHold Timer . . . . . . . . . . . 134 169 3.22. Specify New Attributes (Accept Connections/Peer 170 Oscillation Damping) . . . . . . . . . . . . . . . . . . 135 171 3.23. Event1/Event2 Clean Up . . . . . . . . . . . . . . . . . 136 172 3.24. Events 3, 5, 6 & 7 Give Examples . . . . . . . . . . . . 137 173 3.25. Event 4 & 5 Session Initiation Text . . . . . . . . . . . 138 174 3.26. Event 4 & 5 - bgp_stop_flap option . . . . . . . . . . . 139 175 3.27. Event 5 Clarification . . . . . . . . . . . . . . . . . . 141 176 3.28. Timer Events Definition - Make Consistent . . . . . . . . 141 177 3.29. Event 8 - Clean Up . . . . . . . . . . . . . . . . . . . 142 178 3.30. Hold Timer - Split? . . . . . . . . . . . . . . . . . . . 142 179 3.31. OpenDelay Timer Definition . . . . . . . . . . . . . . . 143 180 3.32. Definition of TCP Connection Accept (Event 13) . . . . . 143 181 3.33. Event 13 & 14 - Valid Addresses & Ports . . . . . . . . . 144 182 3.34. Event 17 - TCP Connection Fails to TCP Connection 183 Termination . . . . . . . . . . . . . . . . . . . . . . . 144 184 3.35. Making Definition Style Consistent . . . . . . . . . . . 145 185 3.36. Event 19 - Definition Cleanup . . . . . . . . . . . . . . 147 186 3.37. Event 22 - Cleanup . . . . . . . . . . . . . . . . . . . 148 187 3.38. FSM Description - ConnectRetry Count . . . . . . . . . . 149 188 3.39. Handling Event 7 (Auto Stop) to Idle State processing . . 149 189 3.40. Clearing the Connection Retry Timer . . . . . . . . . . . 150 190 3.41. Handling of Event 14 in the Connect State . . . . . . . . 151 191 3.42. Handling events 20, 21 in the Connect State and Active 192 State . . . . . . . . . . . . . . . . . . . . . . . . . . 152 193 3.43. Handling the default events in the Connect state . . . . 155 194 3.44. Handling Event 23 in Connect and OpenSent . . . . . . . . 156 195 3.45. Event 17 in the Connect state . . . . . . . . . . . . . . 158 196 3.46. Handling of Event 17 in Active state . . . . . . . . . . 161 197 3.47. Handling of Event 19 in Active state . . . . . . . . . . 161 198 3.48. Handling of Event 2 in Active state . . . . . . . . . . . 162 199 3.49. Default Event handling in Active state . . . . . . . . . 163 200 3.50. Clearing Hold timer in OpenSent, OpenConfirm and 201 Established State . . . . . . . . . . . . . . . . . . . . 164 202 3.51. Clearing Keepalive timer in OpenConfirm and 203 Established State . . . . . . . . . . . . . . . . . . . . 164 204 3.52. Handling Event 18 in the OpenSent state (Keepalive 205 Timer) . . . . . . . . . . . . . . . . . . . . . . . . . 165 206 3.53. Established State MIB . . . . . . . . . . . . . . . . . . 167 207 3.54. State impact of not supporting Optional Events . . . . . 168 208 3.55. New DelayOpen State . . . . . . . . . . . . . . . . . . . 169 209 3.56. Clarify what is covered in the base document . . . . . . 169 210 4. Security Considerations . . . . . . . . . . . . . . . . . . . 170 211 5. Normative References . . . . . . . . . . . . . . . . . . . . 170 212 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 170 214 1. Introduction 216 This document records the issues discussed and the consensus reached 217 in the Interdomain Routing (IDR) Working Group during its efforts to 218 revise and bring up to date the base specification for the BGP-4 219 protocol as documented in RFC1771. The results of these efforts are 220 encoded in RFC4271. The rational for doing this is simple: 221 Experience has demonstrated that the same issues and questions tend 222 to come up again and again. This memo will document not only the 223 decisions on these issues but also how and why the working group 224 reached those conclusions. We hope that this will help make future 225 discussions more fruitful by providing them with a historical 226 context. 228 This document traces the evolution of the BGP-4 base specification 229 from its incarnation as draft-ietf-idr-bgp4-17.txt through the big 230 revision and update push culminating in draft-ietf-idr-bgp4-19.txt. 231 It is divided into two main sections. The first deals with the 232 issues discussed between -17 and -18, and the second deals with the 233 issues discussed between -18 and -19. 235 N.B. There is no rhyme or reason to the numbering scheme other than 236 unique tags to address the issues. 238 2. The Issues from -17 to -18 240 This section lists the issues discussed on the list from late August 241 to late October 2002. 243 2.1. IDR WG Charter 245 Status: Consensus 246 Change: Yes 247 Summary: New charter adopted. 249 Discussion: 251 A variety of discussions surrounded the new charter. The rough 252 consensus is to accept the new charter that the AD's have proposed, 253 and to push as hard a possible to get the base spec to RFC status so 254 other drafts that are dependent can also move forward. 256 For our information, Alex has provided these approximate time lines: 258 Stage Anticipated delay Comment 259 -------------------------------------------------------------------- 260 AD-review 1-4 weeks The document may go back depending on to the WG 261 for the workload AD-review comments to be addressed; this would 262 introduce additional delay. 264 IETF LC 2 weeks Same as above 266 IESG review & 1-2 weeks depending Same as above telechat on when the 267 IETF LC ends 268 -------------------------------------------------------------------- 270 Note that if the document is sent back to the WG at some stage, 271 required changes may warrant an additional WG Last Call. 273 I can personally commit to a 2-week upper bound for the AD-review 274 period. Bill may have a different timer granularity. 276 The opinions expressed on this were 7 in favor, 4 against. 278 This thread has messages subjects of "BGP spec and IDR WG charter" 279 and "IDR WG charter". 281 2.2. TCP Port 283 Status: Consensus 284 Change: Yes 285 Summary: 287 Change: 288 "BGP uses TCP port 179 for establishing its connections." 290 To: 291 "BGP listens on TCP port 179." 293 Discussion: 295 There has been a discussion on clarifying the wording in Section 2, 296 on which port BGP uses. The original text was: 298 "BGP uses TCP port 179 for establishing its connections." 300 The proposed new text is: 302 "BGP listens on TCP port 179." 304 There seems to be a rough consensus that the new text is better. 306 This thread has a message subject of "Review: Section 2, TCP Port 307 179" 309 2.3. FSM wording for what state BGP accepts connections in 311 Status: Consensus 312 Change: No 313 Summary: No change necessary 315 Discussion: 317 An issue was brought up later in the "Review: Section 2, TCP Port 318 179" thread about the words in the FSM for what state BGP accepts 319 connections in. The consensus is that the existing wording is clear. 321 2.4. BGP Identifier/Router ID 323 Status: Consensus 324 Change: No 325 Summary: No change necessary to base draft. Perhaps in a BCP. 327 Discussion: 329 The "admin dist/gp spec proposal", "Router ID" and "bgp spec 330 proposal" threads discussed the BGP Identifier and how close or not 331 it is to IGP's Router ID. The consensus was that this discussion is 332 better saved for a BCP draft, and that it does not need to be 333 contained in the base spec. 335 2.5. Direct EBGP Peers 337 Status: Consensus Change: No Summary: A recollection that ebgp peers 338 must be direct. No text proposed, no discussion. 340 Discussion: 342 Jonathan recalled something that stated that ebgp peers must be 343 direct. No specific sections were quoted. 345 Yakov responded to this with: 347 Section 5.1.3 talks about both the case where ebgp peers are 1 IP hop 348 away from each other: 350 2) When sending a message to an external peer X, and the peer is one 351 IP hop away from the speaker: 353 as well as the case where they are multiple IP hops away from each 354 other: 356 3) When sending a message to an external peer X, and the peer is 357 multiple IP hops away from the speaker (aka "multi hop EBGP"): 359 And emphasized that multi hop EBGP does exist. 361 This came up in the "bgp draft review" thread. 363 2.6. Disallow Private Addresses 365 Status: Consensus 366 Change: No 367 Summary: No change necessary 369 Discussion: 371 In the thread entitled "bgp draft review": 373 Mentioned explicitly disallowing private addresses. The consensus 374 was that there is no reason to disallow them. Which IP addresses 375 peers use is an operational issue. 377 2.7. Renumber Appendix Sections 379 Status: Consensus 380 Change: Yes 381 Summary: Rename/renumber appendix sections so they do not have the 382 same numbers as sections of the main text. 384 Discussion: 386 In the tread entitled "bgp draft review": 388 This thread brought up renaming sections in the appendix to avoid 389 confusion with sections of the same number in the main text. 391 Yakov responded that he would do so in the next edition. 393 2.8. Jitter Text 395 Status: Consensus 396 Change: Yes 397 Summary: 399 Get rid of section 9.2.1.3 ("Jitter"). Move the text to an 400 Appendix: "BGP Timers" Expand text to indicate that jitter applies 401 to all timers, including ConnectRetry. 403 The text for the appendix is listed at the end of the discussion. 405 Discussion: 407 In the tread entitled "bgp draft review": The thread also proposed: 409 "jitter should be applied to the timers associated with 410 MinASOriginationInterval, Keepalive, and 411 MinRouteAdvertisementInterval" 413 Be changed to: 415 "jitter should be applied to the timers associated with ConnectRetry 416 timer" 418 Yakov agreed with making some changes and suggested that we make sure 419 that jitter is applied to all timers. Specifically, he proposes we 420 get rid of section 9.2.1.3 ("Jitter"), move the text of this section 421 into Appendix "BGP Timers", and expand the text to indicate that 422 jitter applies to ConnectRetry timer as well. 424 Jonathan, the original commenter, agreed with Yakov's suggestion. 426 In a follow-up to this issue, there was a question raised about the 427 values we have specified for timers in the document. Specifically: 429 The ConnectRetry timer is should have a value that is 'sufficiently 430 large to allow TCP initialization. Application of jitter can reduce 431 the this value (by up to 25%). A configuration which the 432 ConnectRetry timer has been pegged at a value close to TCP connection 433 time may cause a connection to be terminated as a result of this 434 jitter. Is this a cause for concern ? 436 The default value suggested for ConnectRetry (120 seconds) is 437 sufficiently large that event with a jitter of 0.75, it will be 438 greater than TCP's connection establishment timer. 440 Is adding a jitter to the ConnectRetry timer a standard practice ? 441 What benefit does this provide ? 443 Curtis responded to this with: 445 The TCP connection establishment timer is 75 seconds (sysctl yield 446 "net.inet.tcp.keepinit: 75000" in BSD-oids). 448 The ConnectRetry determines when to make a second attempt after a 449 prior attempt to connect has failed. It is to avoid a rapid 450 succession of retries on immediate failures (for example "Connection 451 refused" if the peer was in the middle of a reboot, Network 452 Unreachable if you can't get there from here, etc) but also covers 453 the case where the TCP SYN goes off and is never heard from again. 455 And Jonathan replied with this information about current practice: 457 It seems to me that if you bring up all bgp peers at once it may lead 458 to load spikes on the network. Cisco seems to wait 27.5 +/- 2.5 459 seconds for IBGP, and 40 +/- 5 seconds for EBGP--20 sec. from config 460 time to the "open active, delay" jittered delay assignment plus the 461 jittered delay (5 to 10 sec. for IBGP, and 15 to 25 sec. for EBGP). 462 This would also apply for "no neighbor x.x.x.x shutdown". Their 463 value of ConnectRetry is 60sec. though, not sure how this value is 464 used (based on above). Maybe some Cisco folks can chime in on this 465 one??? 467 I did not check Juniper. 469 Also, interestingly, they do not apply jitter to the other timers (as 470 far as I can tell), but I don't see a problem with this. 472 Another timer that they use that is not mentioned in the draft/rfc is 473 the next hop resolution timer which is 30 seconds. Although it would 474 be nice to have this in the spec, I will concede that it is out of 475 scope and/or implementation dependent. 477 So the question that arises from this followup, is how does this 478 question affect the text of the appendix on jitter? 480 Curtis replied that we need to only state that jitter should be 481 applied to all timers. Whether a vendor does so or not is a minor 482 deficiency and does not bear on interoperability. Therefore, 483 specifying exact details are not necessary. 485 After Jonathan's response Curtis and Jonathan agreed that jitter 486 should be added to all timers and that we should state so in the 487 text. 489 Yakov proposed the following text for the appendix to discuss jitter: 491 I'd like to propose the following text for "BGP Timers" section: 493 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 494 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 495 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 496 9.2.1.1). 498 The suggested value for the ConnectRetry timer is 120 seconds. 500 The suggested value for the Hold Time is 90 seconds. 502 The suggested value for the KeepAlive timer is 1/3 of the Hold Time. 504 The suggested value for the MinASOriginationInterval is 15 seconds. 506 The suggested value for the MinRouteAdvertisementInterval is 30 507 seconds. 509 An implementation of BGP MUST allow the Hold Time timer to be 510 configurable, and MAY allow the other timers to be configurable. 512 To minimize the likelihood that the distribution of BGP messages by a 513 given BGP speaker will contain peaks, jitter should be applied to the 514 timers associated with MinASOriginationInterval, Keepalive, 515 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 516 shall apply the same jitter to each of these quantities regardless of 517 the destinations to which the updates are being sent; that is, jitter 518 will not be applied on a "per peer" basis. 520 The amount of jitter to be introduced shall be determined by 521 multiplying the base value of the appropriate timer by a random 522 factor which is uniformly distributed in the range from 0.75 to 1.0. 524 Jeff & Ben agreed with this. 526 Justin suggested that we move the range from 0.75 to 1.25 to ensure 527 that the average is around the configured value. Yakov agreed with 528 Justin's changes. Jonathan disagreed, arguing that it was out-of- 529 scope for the task of clarifying the text only. Justin agreed and 530 withdrew his comment. 532 Curtis liked the general text, but suggested these modifications: 534 minor improvement (not really an objection) -- s/suggested value/ 535 suggested default value/g 537 Also 539 s/shall apply the same jitter/may apply the same jitter/ (to each of 540 these quantities regardless of ...). 542 s/jitter will not be applied/jitter need not be configured/ (on a 543 "per peer" basis). 545 He stated that in Avici's implementation they allow a lot of 546 granularity in timer settings, so this reflects current practice. 548 Curtis also suggested changing the last paragraph: 550 The suggested default amount of jitter shall be determined by 551 multiplying the base value of the appropriate timer by a random 552 factor which is uniformly distributed in the range from 0.75 to 1.0. 553 A new random value should be picked each time the timer is set. The 554 range of the jitter random value MAY be configurable. 556 This would make it clear that it is possible to have this timer as 557 configurable and still be within spec. 559 Other comments on Yakov's text pointed out that IOS uses 5 seconds as 560 the default IBGP MinRouteAdvertisementInterval. 562 Tom pointed out that there seems to be a discrepancy between this 563 text and the FSM: The FSM has an OpenDelay timer. And the FSM 564 suggests a HoldTimer of 4 minutes. 566 In following up on this issue, Yakov stated: 568 Here is the final text for the BGP Timers section: 570 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 571 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 572 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 573 9.2.1.1). 575 The suggested default value for the ConnectRetry timer is 120 576 seconds. 578 The suggested default value for the Hold Time is 90 seconds. 580 The suggested default value for the KeepAlive timer is 1/3 of the 581 Hold Time. 583 The suggested default value for the MinASOriginationInterval is 15 584 seconds. 586 The suggested default value for the MinRouteAdvertisementInterval is 587 30 seconds. 589 An implementation of BGP MUST allow the Hold Time timer to be 590 configurable, and MAY allow the other timers to be configurable. 592 To minimize the likelihood that the distribution of BGP messages by a 593 given BGP speaker will contain peaks, jitter should be applied to the 594 timers associated with MinASOriginationInterval, Keepalive, 595 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 596 may apply the same jitter to each of these quantities regardless of 597 the destinations to which the updates are being sent; that is, jitter 598 need not be configured on a "per peer" basis. 600 The suggested default amount of jitter shall be determined by 601 multiplying the base value of the appropriate timer by a random 602 factor which is uniformly distributed in the range from 0.75 to 1.0. 603 A new random value should be picked each time the timer is set. The 604 range of the jitter random value MAY be configurable. 606 With this in mind, I would suggest we mark this issue as closed. 608 Jonathan suggested adding "per peer" to the text, Yakov responded 609 with this text: 611 An implementation of BGP MUST allow the Hold Time timer to be 612 configurable on a per peer basis, and MAY allow the other timers to 613 be configurable. 615 This proposal met with general agreement. This issue is at 616 consensus. 618 2.9. Reference to RFC904 - EGP Protocol 620 Status: Consensus 621 Change: Yes 622 Summary: Add a reference to RFC904 624 Discussion: 626 The "Review Comment: Origin Attribute pg 14" thread suggested adding 627 a reference to RFC904(?), to refer to the EGP protocol. There was no 628 discussion. 630 Yakov agreed to this, and Jonathan seconded it. 632 2.10. Extending AS_PATH Attribute 634 Status: Consensus 635 Change: Yes 636 Summary: Add this to 9.2: 638 If due to the limits on the maximum size of an UPDATE message (see 639 Section 4) a single route doesn't fit into the message, the BGP 640 speaker MUST not advertise the route to its peers and may choose to 641 log an error locally. 643 Discussion: 645 The "Extending AS_PATH attribute length en route" thread brought up 646 the issue of what action should we specify when we receive a route 647 with an AS_PATH that exceeds the defined maximum length. There was 648 some discussion, and it was suggested that, after logging the error, 649 the route not be propagated. 651 Yakov stated that: 653 The real issue here is how to handle the case when a route (a single 654 address prefix + path attributes) doesn't fit into 4K bytes (as the 655 max BGP message size is 4 K). To address this issue I would suggest 656 to add the following to 9.2: 658 After some discussion, Yakov's proposed text's last sentence was 659 dropped and we arrived at: 661 If due to the limits on the maximum size of an UPDATE message (see 662 Section 4) a single route doesn't fit into the message, the BGP 663 speaker may choose not to advertise the route to its peers. 665 In response to Andrew's clarification question to the list, Curtis 666 responded: 668 Wording would be more like: 670 If the attributes for a specific prefix becomes too large to fit the 671 prefix into the maximum sized BGP UPDATE message, the prefix should 672 not be advertised further. Truncation or omission of attributes 673 should not occur unless policies for such modifications are 674 specifically configured. Such policies may contribute to the 675 formation of route loops and are not within the scope of this 676 protocol specification. 678 After some additional discussion, it was decided that we add "and may 679 choose to log an error locally." to the end of Yakov's text. 681 Also, we agreed to change "may choose not to advertise..." to "MUST 682 NOT advertise...". 684 So the text on the table right now is: 686 If due to the limits on the maximum size of an UPDATE message (see 687 Section 4) a single route doesn't fit into the message, the BGP 688 speaker MUST not advertise the route to its peers and may choose to 689 log an error locally. 691 This met with one agreement and no disagreements. We have a 692 consensus. 694 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 696 Status: Consensus 697 Change: Yes 698 Summary: Add this text: 700 The local speaker SHALL then install that route in the Loc-RIB, 701 replacing any route to the same destination that is currently being 702 held in the Loc-RIB. When the new BGP route is installed in the 703 Rout- ing Table, care must be taken to ensure that existing routes to 704 the same destination that are now considered invalid are removed from 705 the Routing Table. Whether or not the new BGP route replaces an 706 existing non-BGP route in the Routing Table depends on the policy 707 configured on the BGP speaker. 709 Discussion: 711 The "Proxy: comments on section 9.1.3" thread brought up some lack of 712 clarity in the section discussing the rules for which routes get 713 propagated from the Loc-RIB into the Adj-RIB-Out. These discussions 714 resulted in a number of suggestions for new text. 716 The first new text was proposed to clarify the issue that the thread 717 first brought up: 719 I agree that this could use some clarification. How about adding to 720 b) in section 9.1: 722 The Loc-RIB must contain only one route per destination; further, it 723 must include all routes that the BGP speaker is using. 725 changing c) in section 9.1.2 to: 727 c) is selected as a result of the Phase 2 tie breaking rules 728 specified in 9.1.2.2, or 730 and adding 732 d) when routing protocols other than BGP are in use, is determined by 733 some other local means to be the route that will actually be used to 734 reach a particular destination. 736 This text was never discussed or a consensus formed on putting it in 737 the document. 739 This modification to 9.1.2 was also proposed to address the same 740 concern: 742 How about changing the paragraph after c) in 9.1.2 to: 744 The local speaker SHALL then install that route in the Loc-RIB, 745 replacing any route to the same destination that is currently being 746 held in the Loc-RIB. This route SHALL then also be installed in the 747 BGP speakers forwarding table. 749 There was one response in the negative to this change, arguing that 750 is is not necessary. 752 Yakov replied to this that: 754 Wrt "adding to b) in section 9.1", the second part (after ";") is 755 redundant as this point is already stated in 3.2. Wrt the first 756 point about Loc-RIB containing just one route per destination, I 757 would suggest to add it to section 3.2, where Loc-RIB is first 758 introduced, rather than adding it to 9.1. 760 Wrt "changing c)... and adding...", I have no objections to add/ 761 modify the text, as suggested above. 763 I am not sure though that changing the paragraph after c) in 9.1.2 is 764 really necessary though, so I would prefer to keep it as is. 766 The "issue 11" thread this was being discussed in then digressed to 767 the topic, now covered in issue 11.3. 769 Ben re-addressed the original issue with this input: 771 I have somewhat of an issue with the paragraph after item c section 772 9.1.2 as discussed. 774 which is => 776 "The local speaker SHALL then install that route in the Loc-RIB, 777 replacing any route to the same destination that is currently being 778 held in the Loc-RIB. If the new BGP route is installed in the 779 Routing Table (as a result of the local policy decision), care must 780 be taken to ensure that invalid BGP routes to the same destination 781 are removed from the Routing Table. Whether or not the new route 782 replaces an already existing non-BGP route in the routing table 783 depends on the policy configured on the BGP speaker." 785 Can we assume that its OK to have a route present in the Loc-RIB and 786 possibly in the adj-RIB-Out but not in the Routing table due to some 787 policy. Won't we violate rule number 1? Only advertise what you 788 use. 790 As conversely implied in this sentence => 792 "If the new BGP route is installed in the Routing Table (as a result 793 of the local policy decision), care must be taken to ensure that 794 invalid BGP routes to the same destination are removed from the 795 Routing Table" 797 I would rephrase the paragraph as follows => 799 "The local speaker SHALL then install that route in the Loc-RIB, 800 replacing any route to the same destination that is currently being 801 held in the Loc-RIB. When the new BGP route is installed in the 802 Routing Table, care must be taken to ensure that existing routes to 803 the same destination that are now considered invalid are removed from 804 the Routing Table. Whether or not the new BGP route replaces an 805 existing non-BGP route in the routing table depends on the policy 806 configured on the BGP speaker." 808 Jeff replied: 810 With the exception that Routing Table should be capitalized 811 throughout, I'd suggest we take this as consensus. 813 Yakov agreed. We are at consensus. 815 2.11.1. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3 817 Status: Consensus 818 Change: Yes 819 Summary: The text below will be added to the -18 version. 821 Discussion: 823 In further discussions around this issue, this text was also 824 proposed: 826 How about adding to section 9.1.3, at the end: 828 Any local-policy which results in reachability being added to an Adj- 829 RIB-Out without also being added to the local BGP speaker's 830 forwarding table is beyond the scope of this document. 832 This suggestion received one response that agreed to this change. 834 This text will be added to the -18 version, and since there were no 835 objections, this issue has been moved to consensus. 837 2.11.2. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2 839 Status: Consensus 840 Change: Yes 841 Summary: Add this text: 843 In the context of this document we assume that a BGP speaker 844 advertises to its peers only those routes that it itself uses (in 845 this context a BGP speaker is said to "use" a BGP route if it is the 846 most preferred BGP route and is used in forwarding). All other cases 847 are outside the scope of this document. 849 Discussion: 851 Additionally this thread produced this section of new text, in 852 section 2: 854 856 "one must focus on the rule that a BGP speaker advertises to its 857 peers (other BGP speakers which it communicates with) in neighboring 858 ASs only those routes that it itself uses." 860 Should be changed to 862 864 "one must focus on the rule that a BGP speaker advertises to its 865 peers (other BGP speakers which it communicates with) in neighboring 866 ASs only routes whose NLRIs are locally reachable." 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 which are locally reachable. Local reachability can 873 be achieved by having any protocol route to the given destination in 874 the routing table." 876 There were a lot of emails exchanged on this topic with a variety of 877 texts proposed (see early in the "Active Route" thread). This issue 878 reopened with Jonathan, who brought up the issue originally, stating 879 that: 881 The issue I raised, and would like to be [re-]considered is with: 883 "one must focus on the rule that a BGP speaker advertises to its 884 peers (other BGP speakers which it communicates with) in neighboring 885 ASs only those routes that it itself uses." 887 Curtis replied that: 889 That is called route origination and it is allowed by: 891 9.4 Originating BGP routes 893 A BGP speaker may originate BGP routes by injecting routing 894 information acquired by some other means (e.g. via an IGP) into BGP. 895 [...] The decision whether to distribute non-BGP acquired routes 896 within an AS via BGP or not depends on the environment within the AS 897 (e.g. type of IGP) and should be controlled via configuration. 899 Advice on what to put in the AS_PATH and NEXT_HOP is in the document. 901 He continued with: 903 I don't think there was ever consensus on what to do with the 904 statement "a BGP speaker advertises to its peers (other BGP speakers 905 which it communicates with) in neighboring ASs only those routes that 906 it itself uses". Some reasonable choices are: 908 1. Omit it (the implied consensus of the rewrite of the paragraph in 909 32.2). 911 2. Leave it as is and put it in another paragraph to separate it 912 from the destination based routing statement. 914 3. Clean up the wording and put it in another paragraph to separate 915 it from the destination based routing statement. 917 The separate paragraph for 2 would be the exact sentence we now have. 919 A BGP speaker advertises to its peers (other BGP speakers which it 920 communicates with) in neighboring ASs only those routes that it 921 itself uses. 923 In possibility 3 we (try to) clear up the ambiguity about the meaning 924 of the word "use" in this sentence. 926 A BGP speaker advertises to its peers (other BGP speakers which it 927 communicates with) in neighboring ASs only those routes that it 928 itself uses. In this context a BGP speaker is said to "use" a BGP 929 route if it is the most preferred BGP route and is either directly 930 used in forwarding or in a specifically configured case where the BGP 931 route would be forwarded internally but IGP forwarding information is 932 used. The latter case reflects a usage in which the IGP is used for 933 forwarding but BGP is originated to IBGP to carry attributes that 934 cannot be carried by the IGP (for example, BGP communities [N]). 935 Other special cases such as virtual routers and multiple instances of 936 BGP on a single router are beyond the scope of this document but for 937 each of these the statement "a BGP speaker advertises to its peers 938 (other BGP speakers which it communicates with) in neighboring ASs 939 only those routes that it itself uses" can (and should in the 940 definition of the extension) be made true with an appropriate 941 definition of the word "use". 943 Unless someone volunteers better wording this may be a good starting 944 point. I thing the last sentence borders on ridiculous in a protocol 945 spec but may be necessary to address specific objections raised on 946 this mailing list. If we want to elaborate on the meaning of the 947 word "use" and address the objections this is what we end up with. 949 Of course looking at what we ended up with, I'd also go along with 950 the other two options (leave it out or put the one sentence in a 951 separate paragraph as is). 953 After some additional discussion (in the "issue 11.2" thread), we 954 have come to a consensus on this text: 956 In the context of this document we assume that a BGP speaker 957 advertises to its peers only those routes that it itself uses (in 958 this context a BGP speaker is said to "use" a BGP route if it is the 959 most preferred BGP route and is used in forwarding). All other cases 960 are outside the scope of this document. 962 This issue is at consensus. 964 2.11.3. Documenting IBGP Multipath 966 Status: Consensus 967 Change: Yes 968 Summary: The documenting of IBGP Multipath is left to another 969 Internet Draft. The consensus is that it should not be in the base 970 spec. 972 Discussion: 974 This thread began in the "issue 11" discussion. In it it was 975 proposed that: 977 There is support in some router vendors to allow more than one BGP 978 route to be installed, for the purpose for load balancing. Given 979 that this is a current practice, and seems to be a useful feature as 980 well, should we insist that only one route be installed in the Loc- 981 RIB ? 983 I would like to suggest that all sections which use MUST in the 984 context of only one route in Loc-RIB be relaxed a little to a SHOULD, 985 and a section added that states that it is possible for a n 986 implementation to add more than one route to the Loc-RIB for the 987 purposes of load balancing. 989 While it will be useful to describe how this situation is the 990 handler, it is perhaps sufficient to even state that handling of this 991 situation is outside the scope of this RFC. 993 I am including some proposed text for this purpose: 995 For the part: 997 > The Loc-RIB must contain only one route per destination; 999 consider instead, 1001 % The Loc-RIB SHOULD contain only one route per destination. % An 1002 implementation may choose to install multiple routes to % a 1003 destination (for the purposes of load balancing). The % handling of 1004 such a configuration, however, is outside the % scope of this RFC. 1006 Perhaps, this can be in section 3.2 instead. 1008 After much discussion back and forth, it was agreed that documenting 1009 IBGP Multipath behavior is a good thing. However, it is something 1010 that belongs in another draft. 1012 Alex opened this issue up again. There were a flurry of responses, 1013 most all of them agreeing with the original consensus that we should 1014 document this feature in a different draft, since it doesn't affect 1015 the core interoperability requirements, and we want to advance the 1016 spec in a timely manner. 1018 Alex persisted in his assertion that this belongs in the base 1019 specification. Right now, the issue is still open. 1021 This discussion later expanded in scope to include all BGP multipath. 1023 Curtis laid out a good description of the various flavors of 1024 multipath: 1026 In addition to IGP multihop, there are two cases of BGP multipath. 1028 In IGP multihop there is one BGP advertisement but to ways to reach 1029 th BGP NEXT_HOP via the IGP. 1031 In one case of BGP multihop, two (or more) IBGP routers peering with 1032 the same external AS have equal routes to a destination and are an 1033 equal cost away from a third router. BGP multihop is applicable to 1034 that third router. Without BGP multihop, BGP would normally pick the 1035 BGP NEXT_HOP of the advertisement from only one of those IBGP peers 1036 (using BGP Identifier) and use that. The IGP lookup would yield one 1037 next hop. With BGP multihop, BGP uses the BGP NEXT_HOP of both 1038 advertisements. Each BGP NEXT_HOP has a different IGP next hop (one 1039 or more IGP next hop). 1041 The second case is where all of the candidates routes for BGP 1042 multipath are external. Seldom does IGP multipath come into play for 1043 EBGP (odd tunneled EBGP multihop cases maybe). Typically the load is 1044 split among two (or more) routers in the same AS. 1046 If in EBGP multipath you split among routers in difference AS, an 1047 aggregate should be formed. This is still prior to the IGP cost rule 1048 in the route selection. 1050 Normally one would not combine IBGP and EBGP in multihop given that 1051 the decision point for multihop is after "d" in 9.1.2.2. If the 1052 multihop decision was prior to "d", then two routers each with an 1053 external peering would forward some of the traffic to each other and 1054 for some src/dst pairs, they'd form a loop. [So don't do that!] 1056 This is getting to be a lot to add to the base spec. I hope we've 1057 convinced you that we should put it in another document. 1059 Curtis later added specific text, that could serve as a start for the 1060 new document (or added to the base spec if the consensus ended up 1061 going the other way): 1063 BGP specifies how to select the single best route. OSPF specifically 1064 defines procedures for handling equal cost multipath (ECMP) [cite 1065 OSPF]. The same technique has been applied to ISIS. A similar 1066 technique has been used with BGP. Variations exist but the decision 1067 to support BGP multipath, the specific variation of BGP multipath, or 1068 not to support it, does not affect interoperability. 1070 A naive implementations of ECMP can cause severe performance 1071 degradation for TCP flows. To avoid this, implementations of BGP 1072 multipath SHOULD maintain packet ordering within microflows as 1073 described in [cite rfc2991, rfc2992]. 1075 BGP multipath, if implemented, SHOULD be disabled by default. 1077 In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there 1078 are two variations of BGP multipath described here. A BGP 1079 implementation may offer both, either one, or neither variation of 1080 BGP multipath. Other variations of BGP multipath may exist, but no 1081 guarantees can be made in this protocol specification of their 1082 properties or impact on interoperability. 1084 Where IGP multipath is used, there is an interaction with BGP learned 1085 routes. The lookup of a BGP NEXT_HOP in the IGP can result in the 1086 selection of an IGP multipath entry. This is not a variation of BGP 1087 multipath. When this occurs, one BGP route is selected as the best 1088 but there is more than one way to reach the BGP NEXT_HOP via the IGP. 1090 In one variation of BGP multipath, a set of more than one IBGP 1091 routers peering with the same external AS have equal routes to a 1092 destination and are an equal IGP cost away from a second set of one 1093 or more routers. BGP multipath is applicable to the latter set of 1094 routers. Without BGP multipath, BGP would pick the BGP NEXT_HOP of 1095 the advertisement from only one of those IBGP peers (using BGP 1096 Identifier) and use only that BGP route. With BGP multipath, BGP 1097 uses the BGP NEXT_HOP of more than one of these equal cost 1098 advertisements, yielding more than one BGP NEXT_HOP. Each BGP 1099 NEXT_HOP has a different IGP next hop (one or more IGP next hop if 1100 IGP multipath is in use). 1102 The second case is where all of the candidates routes for BGP 1103 multipath are external and learned by a single BGP peer. Without BGP 1104 multipath this peer would select only one of the BGP routes and 1105 obtain only one BGP NEXT_HOP. With BGP multipath, more than one 1106 equal cost route is selected yielding more than one BGP NEXT_HOP. 1107 Seldom does IGP multipath come into play when looking up an EBGP 1108 NEXT_HOP but could in principle be applicable. 1110 If in EBGP multipath traffic is split among routers in difference AS, 1111 an aggregate SHOULD be formed so as to propagate a route with an 1112 accurate AS_PATH. If the resulting aggregate is not more specific 1113 than the components, the AS_SET SHOULD NOT be dropped. 1115 The decision point for multipath is after step "d" in Section 9.1.2.2 1116 (prefer externally learned routes). IBGP learned and EBGP learned 1117 routes MUST NOT be combined in multipath. If the multipath decision 1118 is prior to "d", then two routers each with an external peering would 1119 form a routing loop. 1121 The decision point for multipath is generally after step "e" in 1122 Section 9.1.2.2. Some relaxation of the "equal cost" rule (also 1123 applicable to IGP multipath) is possible. In addition to the equal 1124 cost BGP NEXT_HOPS available at BGP route selection, if the IGP next 1125 hop for other BGP NEXT_HOPs are of lower cost, then those may be used 1126 as well. This relaxation of the step "e" is possible but is not 1127 widely implemented (and may not be implemented at all). 1129 The consensus of the majority of the IDR WG is to keep this in a 1130 separate draft and out of the base spec. 1132 2.12. TCP Behavior Wording 1134 Status: Consensus 1135 Change: No 1136 Summary: In issue 19 we decided to remove this section entirely. As 1137 a result the previous consensus on this issue (no change) is needed 1138 moot. 1140 Discussion: The subject-less "your mail" thread discussed a wording 1141 clarification from: 1143 "An implementation that would "hang" the routing information process 1144 while trying to read from a peer could set up a message buffer (4096 1145 bytes) per peer and fill it with data as available until a complete 1146 message has been received. " 1148 To something that is more TCP-correct, such as: 1150 "An implementation that would "hang" the routing information process 1151 while trying to received from a peer could set up a message buffer 1152 (4096 bytes) per peer and fill it with data as available until a 1153 complete message has been received. " 1155 (only change: "read" to "received" This was one of a couple of 1156 suggested changes.) 1158 This suggestion was quite contentious, and although there were a 1159 variety of alternate texts proposed, the only consensus was that this 1160 was a very minor issue, and probably not worth changing. 1162 In issue 19 we decided to remove this section entirely. 1164 2.13. Next Hop for Originated Route 1166 Status: Consensus 1167 Change: No 1168 Summary: No responses, assumed consensus to keep things the same. 1170 Discussion: 1172 There was a one-message thread entitled "next hop for originated 1173 route". This message received no response, so the assumption is that 1174 there is a consensus to keep things as they are. 1176 For related discussion see issue 61. 1178 2.14. NEXT_HOP to Internal Peer 1180 Status: Consensus 1181 Change: No 1182 Summary: Closed in favor of issue 61. 1184 Discussion: 1186 The thread entitled "NEXT_HOP to internal peer" starts with this 1187 question: 1189 When sending a locally originated route to an internal peer, what 1190 should NEXT_HOP be set to? 1192 One response suggested that we add a line stating that the NEXT_HOP 1193 address originates from the IGP. 1195 Since this issue and issue 61 are basically the same, except 61 1196 proposes text, we'll close this issue in favor of 61. 1198 2.15. Grammar Fix 1200 Status: Consensus 1201 Change: Yes 1202 Summary: Change: "The Prefix field contains IP address prefixes ..." 1203 To: "contains an IP address prefix ..." 1205 Discussion: The thread entitled "Review comment: bottom of page 16" 1206 corrects a grammar mistake by suggesting we change: 1208 "The Prefix field contains IP address prefixes ..." 1210 to: 1212 "contains an IP address prefix ..." 1214 Yakov responded that this will be fixed in -18. 1216 The consensus seems to be to correct this, and go with the new text. 1218 2.16. Need ToC, Glossary and Index 1220 Status: Consensus 1221 Change: Yes 1222 Summary: Need to add a Table of Contents (ToC), Glossary and Index to 1223 the draft. Will be added in draft -18. 1225 Discussion: 1227 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests: 1229 1. Document needs, Table of Contents, Glossary, and Index 1231 2. Paths, Routes, and Prefixes need to be defined in the spec early 1232 on (like in a glossary), so it is obvious what is implied. 1234 Yakov responded that draft -18 will have a ToC and definition of 1235 commonly used terms. 1237 2.17. Add References to other RFC-status BGP docs to base spec 1239 Status: Consensus 1240 Change: Yes 1241 Summary: Add references to other RFC-status BGP docs to the base 1242 spec. 1244 Discussion: 1246 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes 1247 titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to 1248 suggest: 1250 3. All BGP Extensions described in other documents that made it to 1251 RFC status should be at least referenced in the Reference section 1252 P.64. This is justifiable since it's the core BGP standard spec. 1254 Yakov responded that this will be added to the -18 review. 1256 Jonathan agreed. 1258 2.18. IP Layer Fragmentation 1260 Status: Consensus 1261 Change: No 1262 Summary: No need to mention IP Layer Fragmentation in the BGP 1263 specification, since this is taken care of at the TCP level. 1265 Discussion: 1267 1. P.6 section 4. Message Formats, its possible for the source BGP 1268 peer IP layer to fragment a message such that the receiving BGP peer 1269 socket layer would have to reassemble it. Need to mention this, 1270 since BGP implementations are required to do this. 1272 The response to this was that, while true, reassembly is something 1273 that is inherent in the TCP layer that BGP rides over. Therefore, 1274 this is something that is in the TCP spec, and needn't be repeated in 1275 the BGP spec. This comment was reaffirmed. There seems to be 1276 consensus that this isn't something that needs to be in the BGP spec. 1278 2.19. Appendix Section 6.2: Processing Messages on a Stream Protocol 1280 Status: Consensus 1281 Change: Yes 1282 Summary: Remove the section entirely, as this is something that does 1283 not belong in the base spec. 1285 Discussion: 1287 This first came up in response to Issue 17: 1289 There was one comment suggesting that section 6.2 (Processing 1290 Messages on a Stream Protocol" mentioned this. 1292 The original reviewer responded that the out-of-scope comment was 1293 out-of-place and referred the responder to section 6.2 (appendix 6) 1295 The original reviewer stated that he is happy with just adding a 1296 reference to section 6.2 in appendix 6 and leaving it at that. 1298 Curtis suggested we just add a reference to Stevens in appendix 6. 1299 6.2 and be done with it. Specifically: 1301 6.2 Processing Messages on a Stream Protocol 1303 BGP uses TCP as a transport mechanism. If you are unsure as to how 1304 to handle asynchronous reads and writes on TCP sockets please refer 1305 to Unix Network Programming [RWStevens] or other introductory text 1306 for programming techniques for the operating system and TCP 1307 implementation that you are using. 1309 There were further suggestions to remove the section entirely as out- 1310 of-scope. At least 3 people agreed with this. 1312 Alex responded that he sees no reason to remove it, but wouldn't have 1313 a problem if the WG decides to do so. 1315 There seems to be general agreement that this section should be 1316 removed. 1318 N.B. This also affects issue 12. 1320 2.20. Wording fix in Section 4.3 1322 Status: Consensus 1323 Change: Yes 1324 Summary: A small change for clarity in section 4.3 1326 Discussion: 1328 This suggestion grew out of the discussion on Issue 18. 1330 The following change was suggested in section 4.3, second line of the 1331 first paragraph: 1333 s/UPDATE packet/UPDATE message/ 1335 Yakov agreed to this change and updated the draft. 1337 2.21. Authentication Text Update 1339 Status: Consensus 1340 Change: No 1341 Summary: The consensus is that additional references to RFC2385 are 1342 not necessary. 1344 Discussion: 1346 P. 10, "Authentication Data:" section you might want to add this, It 1347 is also possible to use MD5 (RFC2385) at the transport layer to 1348 validate the entire BGP message. 1350 Yakov replied to this: 1352 There is already text that covers this: 1354 "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may 1355 be used in addition to BGP's own authentication mechanisms." 1357 .... 1359 "In addition, BGP supports the ability to authenticate its data 1360 stream by using [RFC2385]." 1362 So, I see no need to add the text proposed above. 1364 Ishi agreed with Yakov. Jonathan disagreed since he thought no one 1365 uses BGP auth. Ishi replied that there are lots of people who do use 1366 it. Jonathan replied with a clarification question: "Who uses *BGP's 1367 own* authentication mechanisms???" Ron Bonica replied that they use 1368 BGP auth. There was some additional discussion over who implements 1369 simple password authentication vs. MD5. 1371 After further discussion, the consensus seems to be that we should 1372 leave the text as it is for the reasons Yakov pointed out. There was 1373 some discussion over opening a new issue to discuss deprecating the 1374 BGP auth mechanism discussed in RFC1771 in favor of the mechanism in 1375 RFC2385. 1377 The issue of Deprecating BGP AUTH is discussed in issue 62. 1379 2.22. Scope of Path Attribute Field 1381 Status: Consensus 1382 Change: Yes 1383 Summary: This is already being covered by text that has been added to 1384 the -18 draft. 1386 Discussion: 1388 P. 12, right after "Path Attributes". The following sentence should 1389 be added to this section to clarify the scope of the Path Attribute 1390 field. "All attributes in the Path Attribute field represent the 1391 characteristics of all the route prefixes defined in the NLRI field 1392 of the message". 1394 Yakov replied to this that: 1396 This will be covered by the following text in 3.1 that will be in the 1397 -18 version (see also issue 54). 1399 Routes are advertised between BGP speakers in UPDATE messages. 1400 Multiple routes that have the same path attributes can be advertised 1401 in a single UPDATE message by including multiple prefixes in the NLRI 1402 field of the UPDATE message. 1404 Therefore there is no need to add the sentence proposed above. 1406 There were no objections to this statement, so this issue has been 1407 moved into consensus. 1409 2.23. Withdrawn and Updated routes in the same UPDATE message 1411 Status: Consensus 1412 Change: No 1413 Summary: For various reasons, not least of which is compatibility 1414 with existing implementations, the decision was made to keep thing 1415 the way they are. 1417 Discussion: 1419 4. P.16, last paragraph in section 4.3 as stated, "An UPDATE message 1420 should not include the same address prefix in the WITHDRAWN ROUTES 1421 and Network Layer Reachability Information fields, however a BGP 1422 speaker MUST be able to process UPDATE messages in this form. A BGP 1423 speaker should treat an UPDATE message of this form as if the 1424 WITHDRAWN ROUTES doesn't contain the address prefix." 1426 This complexity could have been avoided if withdrawn routes and NLRI 1427 prefixes with their attributes were mutually exclusive of each other 1428 and appeared in different update messages. If that was the case, the 1429 priority of which field to process first would have been as simple as 1430 using "first come, first served" message processing approach. 1432 Yakov commented that this would make the case where they are both in 1433 the same message unspecified. 1435 John commented that this is something we don't want to change this 1436 late in the game. Although it was acknowledged that this might be a 1437 good change if we were working from a clean slate. 1439 Ben acceded that this was somewhat wishful thinking on his part. 1441 Curtis's comment seems to coincide with this message, stating: 1443 The existing rules are very clear. 1445 Summarized: 1447 If an UPDATE contains only a withdraw for a prefix, then withdraw 1448 whatever route the peer had previously sent. 1450 If an UPDATE contains the prefix only in the NLRI section, replace 1451 whatever route had previously been advertised by the peer or add a 1452 route if there was no previous route, in both cases adding a route 1453 with the current attributes. 1455 Don't put the same prefix in the same in both the withdraw and NLRI 1456 section of the same update. 1458 If you receive an UPDATE with the same prefix in both the withdraw 1459 and NLRI, ignore the withdraw. [Some older implementations thought 1460 this was a good way to say "delete then add".] 1462 Process UPDATEs from the same peer in the order received. 1464 And goes on to say, that to him, these rules are clear from the 1465 existing text. 1467 Consensus is that while this would be nice, we need to stick with 1468 what we have, and move on. 1470 2.24. Addition or Deletion of Path Attributes 1472 Status: Consensus 1473 Change: Yes 1474 Summary: Add the following to section 3.1: 1476 Changing the attributes of a route is accomplished by advertising a 1477 replacement route. The replacement route carries new (changed) 1478 attributes and has the same NLRI as the original route. 1480 Discussion: 1482 5. P. 20 Its not stated how we delete or modify Path Attributes 1483 associated with NLRI prefixes. 1485 A response to this comment said that this is implicit in the 1486 definition of "route" and the general withdraw/replace behavior and 1487 therefore doesn't need to be repeated. 1489 Ben responded saying that, while there was an assumption, there was 1490 no well defined mechanism, and this leads to ambiguity. 1492 John responded, no need to define everything explicitly, or we'll be 1493 here forever. 1495 Picking this thread up again, Yakov argued: 1497 By *definition* a route is a pair. From that 1498 definition it follows that changing one or more path attributes of a 1499 route means changing a route, which means withdrawing the old route 1500 (route with the old attributes) from service and advertising a new 1501 route (route with the new attributes). Procedures for doing this are 1502 well-defined (see section 3.1), and therefore no new text to cover 1503 this is needed. 1505 Jonathan agreed with this statement, but Ben argued that the text in 1506 section 3 is insufficient the way it is currently written. After two 1507 iterations, Ben and Yakov agreed on this formulation for an update to 1508 section 3.1: 1510 Changing the attributes of a route is accomplished by advertising a 1511 replacement route. The replacement route carries new (changed) 1512 attributes and has the same NLRI as the original route. 1514 Jeff objected somewhat to the wording, since, because of a bgp route 1515 is defined as a pair, changing either part of 1516 that pair, by definition, changes the route. He acknowledged that 1517 this might fall under the category of implementation detail. 1519 Yakov presented the view that he thought we were at consensus with 1520 the text he proposed above. Jonathan agreed. There were no 1521 objections, so this is moved to Consensus. 1523 2.25. NEXT_HOP Semantics 1525 Status: Consensus 1526 Change: No 1527 Summary: After responders pointed out another sentence, this comment 1528 was resolved. Things will stay the way they are. 1530 Discussion: 1532 1. P.28, 2nd to last paragraph. The line that reads, "To be 1533 semantically correct, the IP address in the NEXT_HOP must not be the 1534 IP address of the receiving speaker, and the NEXT_HOP IP address must 1535 either be the sender's IP address (used to establish the BGP 1536 session), or the interface associated with the NEXT_HOP IP address 1537 must share a common subnet with the receiving BGP speaker..." 1539 This is not always true, what if the current ASBR BGP router is 1540 advertising an external AS route (to a IBGP Peer) whose NEXT_HOP IP 1541 address is the IP address of the EBGP peer in the other AS? 1543 A response to this pointed out that right before this is a sentence 1544 stating that this only applied to eBGP links, and only when the peers 1545 are one hop from each other, so a modification is unnecessary. This 1546 response was confirmed with another. 1548 The original reviewer acknowledged this and withdrew the comment. 1550 The consensus is to leave things the way they are. 1552 2.26. Attributes with Multiple Prefixes 1554 Status: Consensus 1555 Change: No 1556 Summary: After some discussion, the consensus is to keep things the 1557 same since the suggested behavior is defined in the message format. 1559 Discussion: 1561 2. P. 29, Section 6.3. Add this rule near the attribute rules. 1562 "Multiple prefixes that require the same attribute type with 1563 different values must never appear in the same update message". 1565 A response to this suggested that this text is unnecessary since this 1566 behavior is ruled out by the way the message format is defined. 1568 The original commenter agrees with the responder. The consensus is 1569 to leave things the way they are. 1571 2.27. Allow All Non-Destructive Messages to Refresh Hold Timer 1573 Status: Consensus 1574 Change: No 1575 Summary: It is agreed that this is a change that exceeds the original 1576 goal of this draft revision. This goal is to document existing 1577 practice in an interoperable way. 1579 Discussion: 1581 3. P. 29, Section 6.5, Please rewrite this sentence from: "If a 1582 system does not receive successive KEEPALIVE and/or UPDATE and/or 1583 NOTIFICATION messages within the period specified in the Hold Time 1584 field of the OPEN message ..." 1586 To This: "If a system does not receive successive KEEPALIVE and/or 1587 UPDATE and/or any other BGP message within the period specified in 1588 the Hold Time field of the OPEN message ..." 1590 There is disagreement on this change. It has been discussed in other 1591 threads. 1593 The original commenter acknowledged that this is something that would 1594 be "adding a new feature" as opposed to the stated goal of 1595 "documenting what exists." He suggested that the ADs decide if we 1596 should open the door for new features or not. 1598 Yakov replied to this that he would suggest we keep things as is, 1599 since the purpose is to document current implementations. 1601 This did not meet with any objections, so this issue has been moved 1602 into consensus. 1604 2.28. BGP Identifier as Variable Quantity 1606 Status: Consensus 1607 Change: No 1608 Summary: The consensus is that changing the BGP Identifier in the 1609 base draft is out-of-scope at this point in the draft evolution. 1611 Discussion: 1613 4. P. 31, section 6.8, Please rewrite this sentence from: "Comparing 1614 BGP Identifiers is done by treating them as (4-octet long) unsigned 1615 integers." 1617 To This: "Comparing BGP Identifiers is done by treating them as large 1618 numbers based on their IP Address type (e.g. IPv4, IPv6, etc.)." 1620 A response to this was that since BGP Identifier is defined in the 1621 base spec as a 4 byte unsigned integer, and not a variable quantity, 1622 the sentence as written is acceptable. This was also confirmed by 1623 another response. 1625 The original commenter was thinking of IPv6, and providing sufficient 1626 space to allow a full v6 address to be used. 1628 Again, responders said that this is out-of-scope for the current 1629 draft. 1631 2.29. State Why Unresolveable Routes Should Be Kept in Adj-RIB-In 1633 Status: Consensus 1634 Change: Yes 1635 Summary: Add: 1637 "in case they become resolvable" after the last sentence on p. 46. 1639 Discussion: 1641 5. P.46, last sentence, "However, corresponding unresolvable routes 1642 SHOULD be kept in the Adj-RIBs-In." It would helpful if the author 1643 states why unresolvable routes should be kept in Adj-RIBs-In? 1645 A response to this stated "In case they become resolvable" 1647 Yakov responded that: 1649 I suggest we add "in case they become resolvable" after the last 1650 sentence on p. 46. 1652 The original commenter stated that: Then the point that the peer will 1653 not refresh the route if we drop them (unless we use Route Refresh) 1654 because they are unreachable should be made. 1656 Yakov also responded that: 1658 This should be clear from the following text in Section 3: 1660 The initial data flow is the portion of the BGP routing table that is 1661 allowed by the export policy, called the Adj-Ribs-Out (see 3.2). 1662 Incremental updates are sent as the routing tables change. BGP does 1663 not require periodic refresh of the routing table. 1665 Jonathan, who was the original commenter, agreed with both the 1666 changed text and the clarity of section 3. 1668 2.30. Mention Other Message Types 1670 Status: Consensus 1671 Change: Yes 1672 Summary: Add a reference to RFC2918 at the end of the type code list. 1674 Discussion: 1676 1. P. 7 Type: Need to add the new message types such as, Capability 1677 Negotiations (RFC2842), Route Refresh, etc. 1679 One response argued that these are out-of-scope of the base document. 1680 One response agreed, but thought that it should be capability and not 1681 message type. The original commenter responded about Message type 1682 from the capability draft. 1684 Sue mentioned this would be added in the second round. 1686 Yakov replied that: 1688 The only new message type that is covered by an RFC (rather than just 1689 an Internet Draft) is the Refresh message. With this in mind how 1690 about replacing the following: 1692 The following type codes are defined: 1694 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE 1696 with 1697 This document defines the following type codes: 1699 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE 1701 [RFC2918] defines one more type code. 1703 Jonathan agreed with this change. This issue has been moved to 1704 consensus. 1706 2.31. Add References to Additional Options 1708 Status: Consensus 1709 Change: Yes 1710 Summary: Consensus to add: 1712 [RFC2842] defines another Optional Parameter. 1714 Discussion: 1716 2. P. 9, right after "This document defines the following optional 1717 parameters:" Need to mention possible options, such as: Capabilities 1718 (RFC2842), Multiprotocol extensions (RFC2858), Route Refresh 1719 (RFC2918). 1721 One response agreed that adding references would be fine. A second 1722 response agreed. 1724 Yakov replied that: 1726 Please note that only rfc2842 defines an OPEN optional parameter. 1727 Neither rfc2858 nor rfc2918 defines an OPEN optional parameter. 1729 With this in mind I would suggest to add the following text: 1731 [RFC2842] defines another Optional Parameter. 1733 The original poster agreed with this modification. This issue is at 1734 consensus. 1736 2.32. Clarify EGP Reference 1738 Status: Consensus 1739 Change: No 1740 Summary: The consensus is that this was addressed in 32.1, so we can 1741 close this. 1743 Discussion: 1745 3. P. 13, EGP, are there other EGP protocols other than BGP that are 1746 in use? If not, change EGP to BGP. 1748 A response to this suggested that we add a reference to [1] (the EGP 1749 spec) here. 1751 Another response clarified that this refers to EGP-the-protocol and 1752 NOT the class. 1754 Another response disagreed, but suggested that: 1756 IGP = network was explicitly introduced into bgp (network cmd) 1757 INCOMPLETE = network was implicitly introduced into bgp 1758 (redistribute) EGP = other 1760 The original commenter thought that this referred to EGP-the-class of 1761 protocols. And why not use BGP therefore, as the only EGP. 1763 There was some discussion over whether or not we should mention 1764 something that is historical. 1766 Jeff suggested a footnote in the Origin section about EGP. 1768 Curtis suggested that we state that the EGP in ORIGIN is deprecated, 1769 but retain the value to document what it used to mean. 1771 This reviewer thinks a statement about whether this "EGP" origin 1772 refers to the protocol or the class or protocols would be useful. 1774 Yakov replied that an EGP reference will be added (see issue 9). 1776 Yakov also stated that he doesn't see what is wrong with the current 1777 text, and suggested we keep it. This includes leaving out any 1778 reference to the status of the EGP spec. He sees that it is clear 1779 from context that we are talking about "the EGP" [RFC904]. 1781 Jeff noted that this issue has been sufficiently addressed in the 1782 solution to 32.1. This met with agreement. We are at consensus. 1784 2.32.1. EGP ORIGIN Clarification 1786 Status: Consensus 1787 Change: Yes 1788 Summary: Change section 5.1.1 to read: 1790 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1791 shall be generated by the speaker that originates the associated 1792 routing information. Its value SHOULD NOT be changed by any other 1793 speaker." 1795 Consensus to change: 1797 1 EGP - Network Layer Reachability Information learned via the EGP 1798 protocol 1800 to: 1802 1 EGP - Network Layer Reachability Information learned via the EGP 1803 protocol [RFC904] 1805 Discussion: 1807 This discussion is picked up again in the "Review of 1808 draft-ietf-idr-bgp4-17" thread, where specific text is proposed: 1810 Old: 1812 "ORIGIN is a well-known mandatory attribute that defines the origin 1813 of the path information. The data octet can assume the following 1814 values: 1816 Value Meaning 1818 0 IGP - Network Layer Reachability Information is interior to the 1819 originating AS 1821 1 EGP - Network Layer Reachability Information learned via the EGP 1822 protocol 1824 2 INCOMPLETE - Network Layer Reachability Information learned by some 1825 other means" New: 1827 "ORIGIN is a well-known mandatory attribute that defines the origin 1828 of the path information. The data octet can assume the following 1829 values: 1831 Value Meaning 1833 0 IGP - NLRI was explicitly introduced into bgp 1835 1 EGP - this value was administratively configured to affect policy 1836 decisions or NLRI was learned via the EGP protocol [1] 1838 2 INCOMPLETE - NLRI was implicitly introduced into bgp" 1840 since: 1) The network command sets the origin to IGP and I remember 1841 seeing somewhere that only static routes should be set to IGP. 2) The 1842 primary use of EGP value is policy 3) EGP seems to still exist, 1843 anyway even if it does not it is not worth re-writing the world. 1845 Also, change: "5.1.1 ORIGIN 1847 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1848 shall be generated by the autonomous system that originates the 1849 associated routing information. It shall be included in the UPDATE 1850 messages of all BGP speakers that choose to propagate this 1851 information to other BGP speakers." 1853 to: "5.1.1 ORIGIN 1855 The value of the ORIGIN attribute shall be set by the speaker that 1856 originates the associated NLRI. Its value shall not be changed by 1857 any other speaker unless the other speaker is administratively 1858 configured to do so to affect policy decisions." 1860 since: 1) It is already defined as well-known mandatory attribute. 2) 1861 It may be set differently within the same AS (not saying this is 1862 good). 3) It is commonly used for policy, but by default does not get 1863 changed. 4) Speakers have no choice, it is mandatory. 1865 After much continued discussion on this in the "issue 32.1" thread, 1866 we seem to have come to a consensus that section 5.1.1 should read: 1868 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1869 shall be generated by the speaker that originates the associated 1870 routing information. Its value should not be changed by any other 1871 speaker unless the other speaker is administratively configured to do 1872 so to affect policy decisions." 1874 This text met with a number of agreements, and one disagreement 1875 stating that we shouldn't have the "unless administratively 1876 configured" portion. 1878 After some further discussion, we have this text on the table: 1880 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1881 generated by the BGP speaker that originates the associated BGP 1882 routing information. The attribute shall be included in the UPDATE 1883 messages of all BGP speakers that choose to propagate this 1884 information to other BGP speakers. 1886 Jonathan suggested that we change "propagate this information" to 1887 "forward this route". He also mentioned that he would prefer 1888 something more explicit instead of/in addition to "The attribute 1889 shall be included in the UPDATE messages of all BGP speakers that 1890 choose to propagate this information to other BGP speakers." such as 1891 "other speakers do not change the ORIGIN value." 1893 On the issue of making the EGP ORIGIN type more clear Andrew 1894 proposed: 1896 To me, there seems to be sufficient confusion around the "EGP" 1897 reference to merit some sort of clarification. The simplest 1898 modification would be to change: 1900 1 EGP - Network Layer Reachability Information learned via the EGP 1901 protocol 1903 to: 1905 1 EGP - Network Layer Reachability Information learned via the EGP 1906 protocol [RFC904] 1908 That would clarify that we're talking about the protocol, and not the 1909 class-of-protocols, or EBGP. It would leave unstated that this could 1910 theoretically be used to muck with route selection. I think that is 1911 ok. If operators want to override ORIGIN to affect some hoho magic, 1912 they are welcome to do so, but I don't think it needs to be 1913 documented in the base spec. 1915 This met with a number of agreements. 1917 On the second text section we are working on, Jonathan objected to 1918 the current working text below and suggested an alternate: 1920 CHANGE: 1922 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1923 generated by the BGP speaker that originates the associated BGP 1924 routing information. The attribute shall be included in the UPDATE 1925 messages of all BGP speakers that choose to propagate this 1926 information to other BGP speakers." 1928 TO: 1930 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1931 shall be generated by the speaker that originates the associated 1932 routing information. Its value should not be changed by any other 1933 speaker unless the other speaker is administratively configured to do 1934 so to affect policy decisions." 1936 -or- 1937 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1938 shall be generated by the speaker that originates the associated 1939 routing information. Its value should not be changed by any other 1940 speaker." 1942 Jonathan cited a recent example of someone who was still confused by 1943 this section of the text in -17 (not specifically the working text). 1945 Yakov proposed this as final text: 1947 In 4.3: 1949 a) ORIGIN (Type Code 1): 1951 ORIGIN is a well-known mandatory attribute that defines the origin of 1952 the path information. The data octet can assume the following 1953 values: 1955 Value Meaning 1957 0 IGP - Network Layer Reachability Information is interior to the 1958 originating AS 1960 1 EGP - Network Layer Reachability Information learned via the EGP 1961 protocol [RFC904] 1963 2 INCOMPLETE - Network Layer Reachability Information learned by some 1964 other means 1966 Usage of this attribute is defined in 5.1.1. 1968 In 5.1.1: 1970 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1971 shall be generated by the speaker that originates the associated 1972 routing information. Its value SHOULD NOT be changed by any other 1973 speaker." 1975 This met with agreement. This issue is at consensus. 1977 2.32.2. BGP Destination-based Forwarding Paradigm 1979 Status: Consensus 1980 Change: Yes 1981 Summary: After much discussion, this is the consensus: This text in 1982 the current draft: 1984 To characterize the set of policy decisions that can be enforced 1985 using BGP, one must focus on the rule that a BGP speaker advertises 1986 to its peers (other BGP speakers which it communicates with) in 1987 neighboring ASs only those routes that it itself uses. This rule 1988 reflects the "hop-by-hop" routing paradigm generally used throughout 1989 the current Internet. Note that some policies cannot be supported by 1990 the "hop-by-hop" routing paradigm and thus require techniques such as 1991 source routing (aka explicit routing) to enforce. For example, BGP 1992 does not enable one AS to send traffic to a neighboring AS intending 1993 that the traffic take a different route from that taken by traffic 1994 originating in the neighboring AS. On the other hand, BGP can 1995 support any policy conforming to the "hop-by-hop" routing paradigm. 1996 Since the current Internet uses only the "hop-by-hop" inter-AS 1997 routing paradigm and since BGP can support any policy that conforms 1998 to that paradigm, BGP is highly applicable as an inter-AS routing 1999 protocol for the current Internet. 2001 will be replaced in -18 with the following text: 2003 Routing information exchanged via BGP supports only the destination- 2004 based forwarding paradigm, which assumes that a router forwards a 2005 packet based solely on the destination address carried in the IP 2006 header of the packet. This, in turn, reflects the set of policy 2007 decisions that can (and can not) be enforced using BGP. Note that 2008 some policies cannot be supported by the destination-based forwarding 2009 paradigm, and thus require techniques such as source routing (aka 2010 explicit routing) to be enforced*. Such policies can not be enforced 2011 using BGP either. For example, BGP does not enable one AS to send 2012 traffic to a neighboring AS for forwarding to some destination 2013 (reachable through but) beyond that neighboring AS intending that the 2014 traffic take a different route to that taken by the traffic 2015 originating in the neighboring AS (for that same destination). On 2016 the other hand, BGP can support any policy conforming to the 2017 destination-based forwarding paradigm. 2019 Discussion: 2021 In response to these proposals, Yakov proposed that the real problem 2022 is that it is not clear that BGP is build to support the destination- 2023 based forwarding paradigm. To fix this, it was proposed that: 2025 2027 To characterize the set of policy decisions that can be enforced 2028 using BGP, one must focus on the rule that a BGP speaker advertises 2029 to its peers (other BGP speakers which it communicates with) in 2030 neighboring ASs only those routes that it itself uses. This rule 2031 reflects the "hop-by-hop" routing paradigm generally used throughout 2032 the current Internet. Note that some policies cannot be supported by 2033 the "hop-by-hop" routing paradigm and thus require techniques such as 2034 source routing (aka explicit routing) to enforce. For example, BGP 2035 does not enable one AS to send traffic to a neighboring AS intending 2036 that the traffic take a different route from that taken by traffic 2037 originating in the neighboring AS. On the other hand, BGP can 2038 support any policy conforming to the "hop-by-hop" routing paradigm. 2039 Since the current Internet uses only the "hop-by-hop" inter-AS 2040 routing paradigm and since BGP can support any policy that conforms 2041 to that paradigm, BGP is highly applicable as an inter-AS routing 2042 protocol for the current Internet. 2044 2046 Routing information exchanged via BGP supports only the destination- 2047 based forwarding paradigm, which assumes that a router forwards a 2048 packet based solely on the destination address carried in the IP 2049 header of the packet. This, in turn reflects the set of policy 2050 decisions that can (and can not) be enforced using BGP. Note that 2051 some policies cannot be supported by the destination-based forwarding 2052 paradigm and thus require techniques such as source routing (aka 2053 explicit routing) to enforce. Such policies can not be enforced 2054 using BGP either. For example, BGP does not enable one AS to send 2055 traffic to a neighboring AS intending that the traffic take a 2056 different route from that taken by traffic originating in the 2057 neighboring AS. On the other hand, BGP can support any policy 2058 conforming to the destination-based forwarding paradigm. 2060 Curtis thinks the newer text here is more clear. 2062 In response to the new text, Christian Martin proposed a slightly 2063 different new text: 2065 Routing information exchanged via BGP supports only the destination- 2066 based forwarding paradigm, which assumes that a router forwards a 2067 packet based solely on the destination address carried in the IP 2068 header of the packet. This, in turn reflects the set of policy 2069 decisions that can (and can not) be enforces using BGP. Note that 2070 some policies cannot be supported by the destination-based forwarding 2071 paradigm and thus require techniques such as source routing (aka 2072 explicit routing) to enforce. Such policies can not be enforced 2073 using BGP either. For example, BGP does not enable one AS to send 2074 traffic to a neighboring AS based on prefixes originating from the 2075 local AS. On the other hand, BGP can support any policy conforming 2076 to the destination-based forwarding paradigm. 2078 To which Yakov replied: 2080 Routing information exchanged via BGP supports only the destination- 2081 based forwarding paradigm, which assumes that a router forwards a 2082 packet based solely on the destination address carried in the IP 2083 header of the packet. This, in turn, reflects the set of policy 2084 decisions that can (and can not) be enforces using BGP. Note that 2085 some policies cannot be supported by the destination-based forwarding 2086 paradigm, and thus require techniques such as source routing (aka 2087 explicit routing) to enforce. Such policies can not be enforced 2088 using BGP either. For example, BGP does not enable one AS to send 2089 traffic through a neighboring AS to some destination (which is 2090 outside of the neighboring AS, but is reachable through the 2091 neighboring AS) intending that the traffic take a different route 2092 from that taken by the traffic to the same destination that 2093 originating in the neighboring AS. On the other hand, BGP can 2094 support any policy conforming to the destination-based forwarding 2095 paradigm. 2097 And Chris responded: 2099 Routing information exchanged via BGP supports only the destination- 2100 based forwarding paradigm, which assumes that a router forwards a 2101 packet based solely on the destination address carried in the IP 2102 header of the packet. This, in turn, reflects the set of policy 2103 decisions that can (and can not) be enforces using BGP. Note that 2104 some policies cannot be supported by the destination-based forwarding 2105 paradigm, and thus require techniques such as source routing (aka 2106 explicit routing) to enforce. Such policies can not be enforced 2107 using BGP either. For example, BGP does not enable one AS to send 2108 traffic through a neighboring AS to some destination beyond the 2109 neighboring AS intending that the traffic take a different route from 2110 that taken by traffic to the same destination which originates in the 2111 neighboring AS. In other words, the BGP policy of a local AS cannot 2112 affect the downstream (aka, away from the local AS) forwarding policy 2113 of a remote AS. On the other hand, BGP can support any policy 2114 conforming to the destination-based forwarding paradigm. 2116 Tom Petch preferred Yakov's second formulation, with these changes: 2118 policies can not be enforced using BGP either. For example, BGP does 2119 not enable one AS to send traffic ! to a neighboring AS for 2120 forwarding to some destination (reachable through but) beyond ! that 2121 neighboring AS intending that ! the traffic take a different route to 2122 that taken by the traffic ! originating in the neighboring AS (for 2123 that same destination). 2125 On the other hand, BGP can support any policy conforming to the 2126 destination-based forwarding paradigm. 2128 Yakov agreed to Tom's suggested changes. 2130 2.33. Add "Optional Non-Transitive" to the MED Section 2132 Status: Consensus 2133 Change: Yes 2134 Summary: Add "Optional Non-Transitive" to MED Section Add "well-known 2135 mandatory" to the NEXT_HOP Section 2137 Discussion: 2139 4. P.23, change the following: 2141 "The MULTI_EXIT_DISC attribute may be used on external (inter-AS) 2142 links to discriminate among multiple exit or entry points to the same 2143 neighboring AS ..." 2145 To the following: 2147 "The MULTI_EXIT_DISC is an optional non-transitive attribute which 2148 may be used on external (inter-AS) links to discriminate among 2149 multiple exit or entry points to the same neighboring AS ..." 2151 A responder disagreed, and stated reasons "covered elsewhere" 2152 Original commenter asked for reasons, since the modification seemed 2153 obvious to him. 2155 Yakov agreed to make this change in -18. 2157 Jonathan replied that: 2159 5.1.3 NEXT_HOP also, it is missing " well-known mandatory". 2161 Yakov also agreed to make this change. 2163 2.34. Timer & Counter Definition 2165 Status: Consensus 2166 Change: No 2167 Summary: No discussion, no text proposed, defaults to consensus for 2168 no change. 2170 Discussion: 2172 5. In section 8, there are a number of Timers, Counters, etc. that 2173 need to be explicitly defined before they are used by the FSM. 2174 Perhaps these definitions should go in the Glossary section. 2176 There has been no further discussion on this issue. Unless it is 2177 brought up again, this issue is in consensus, with no change. 2179 2.35. Fix Typo 2181 Status: Consensus 2182 Change: Yes 2183 Summary: Fix a Typo. No discussion, but this seem clear. 2185 Discussion: 2187 1. P. 41. Typing error, "Each time time the local system...". 2189 2.36. Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 2191 Status: Consensus 2192 Change: Yes 2193 Summary: This change requires a glossary. Yakov has committed to 2194 having a section where commonly used terms are defined in draft 18, 2195 so this issue is at consensus. 2197 Discussion: 2199 2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in 2200 the glossary, so when they are used in section 9.1, it is well 2201 understood what they are. 2203 Yakov replied: 2205 will be added to the section "Definition of commonly used terms" in 2206 -18 version. 2208 2.37. Combine "Unfeasible Routes" and "Withdrawn Routes" 2210 Status: Consensus 2211 Change: Yes 2212 Summary: Add the following terms to the "commonly used terms 2213 section": 2215 Feasible route A route that is available for use. 2217 Unfeasible route A previously advertised feasible route that is no 2218 longer available for use. 2220 Discussion: 2222 3. P. 45, Phase I, There is no definition of what are unfeasible 2223 routes? Are they the same as withdrawn routes? If so, the two 2224 should be combined to one name. 2226 Ishi replied to this that he thought that we could combine the two 2227 terms, since there is limited difference from an implementation 2228 standpoint. 2230 Yakov replied: 2232 The routes are withdrawn from service because they are unfeasible, 2233 not because they are "withdrawn". So, we need to keep the term 2234 "unfeasible" to indicate the *reason* why a route could be withdrawn. 2235 On the other hand, "withdrawn" is used as a verb, and to the best of 2236 my knowledge "unfeasible" can't be used as a verb. With this in 2237 mind, I don't think that we can combine the two into a single term. 2239 Ishi replied that he was convinced, and that the terms should stay 2240 separate. 2242 Andrew asked the list if we should define these terms in the 2243 "commonly used terms" section in draft -18. 2245 Ben replied that if we use them a lot, we should define them, and if 2246 not local definitions will suffice. 2248 There was some back and forth about the necessity of defining terms 2249 which should be obvious. 2251 mrr actually checked the doc to see if we were consistently using the 2252 terms, and found: 2254 It turns out there there is an inconsistency in the usage of the word 2255 withdrawn. 2257 Section 3.1: 2259 There are three methods by which a given BGP speaker can indicate 2260 that a route has been withdrawn from service: 2262 ... 2264 b) a replacement route with the same NLRI can be advertised, or 2266 ... 2268 Later, in the definition of Withdrawn Routes Length, we have: 2270 A value of 0 indicates that no routes are being withdrawn from 2271 service, 2273 Taken together, this could be construed as meaning that a Withdrawn 2274 Routes Length of 0 indicates that all routes included in the UPDATE 2275 represent newly feasible routes... not replacement routes. 2277 Now, it's possible that this problem has been removed by changes to 2278 the text that have not yet been incorporated in to a new draft; 2279 however, it arose because the text, for the most part, does _not_ use 2280 "withdrawn" in the standard way. Instead, it refers to routes 2281 included in the WITHDRAWN ROUTES field of an UPDATE message. 2282 Consequently, I propose defining a "withdrawn route" as follows: 2284 Withdrawn route: a route included in the WITHDRAW ROUTES field of an 2285 UPDATE message. 2287 Regardless of whether or not this definition is included, Section 3.1 2288 should be changed from: 2290 There are three methods by which a given BGP speaker can indicate 2291 that a route has been withdrawn from service: 2293 to: 2295 There are three methods by which a given BGP speaker can indicate 2296 that a route has been removed from service: 2298 or: 2300 There are three methods by which a given BGP speaker can indicate 2301 that a route is now unfeasible: 2303 After some further off-list discussion, mrr agreed that this 2304 inconsistency is extremely minor, and withdrew his comment. feasible 2305 and unfeasible route will be defined in the "commonly used terms" 2306 section to clear up any confusion. 2308 2.38. Clarify Outbound Route Text 2310 Status: Consensus 2311 Change: No 2312 Summary: Consensus that the issue was sufficiently minor to leave 2313 things alone. 2315 Discussion: 2317 4. P. 50, line, "If a route in Loc-RIB is excluded from a particular 2318 Adj-RIB-Out the previously advertised route in that Adj-RIB-Out must 2319 be withdrawn from service by means of an UPDATE message (see 9.2)." 2321 Would like to rephrase the sentence for clarity, "If a route in Loc- 2322 RIB is excluded from a particular Adj-RIB-Out and was previously 2323 advertised via Adj-RIB-Out, it must be withdrawn from service by 2324 means of an UPDATE message (see 9.2)." 2326 One comment suggested either leave it alone, or remove "via Adj-RIB- 2327 Out". 2329 The original commenter withdrew the comment. 2331 2.39. Redundant Sentence Fragments 2333 Status: Consensus 2334 Change: Yes 2335 Summary: Fix typo & parentheses. 2337 Discussion: 2339 5. P. 50, section 9.1.4, The two fragments of this sentence are 2340 redundant and don't say anything new or simplify the content. Just 2341 keep one fragment. 2343 "A route describing a smaller set of destinations (a longer prefix) 2344 is said to be more specific than a route describing a larger set of 2345 destinations (a shorted prefix); similarly, a route describing a 2346 larger set of destinations (a shorter prefix) is said to be less 2347 specific than a route describing a smaller set of destinations (a 2348 longer prefix)." 2350 There was a comment that disagreed, thinking that both "more 2351 specific" and "less specific" need to be defined. And suggested that 2352 only the third and forth parentheses need to be dropped. 2354 The original commenter agreed with the parentheses changes. 2356 Yakov agreed to drop the third and fourth parentheses in the -18 2357 version. 2359 Jonathan replied to this: 2361 Disagree, the text if fine the way it is, except you need to change 2362 "shorted" to "shorter". 2364 After minimal further discussion, it was decided we are at a 2365 consensus on this issue to fix the typo and drop the third and fourth 2366 parentheses. 2368 2.40. Section 9.2.1.1 - Per Peer vs. Per Router 2369 MinRouteAdvertisementInterval 2371 Status: Consensus 2372 Change: No 2373 Summary: The consensus is that current practice allows for the 2374 MinRouteAdvertisementInterval to be set per peer, so the text should 2375 be kept the same. 2377 Discussion: 2379 6. P. 52, section 9.2.1.1 Change this sentence for clarity, "This 2380 rate limiting procedure applies on a per-destination basis, although 2381 the value of MinRouteAdvertisementInterval is set on a per BGP peer 2382 basis." 2384 To This: "This rate limiting procedure applies on a per-destination 2385 basis, although the value of MinRouteAdvertisementInterval is set on 2386 a BGP router (same value for all peers) basis." 2388 There was a comment disagreeing with this proposal. It was later 2389 elaborated on to include that the reason for disagreement was that 2390 the proposed changes changed the protocol and not just a practice 2391 clarification. Ben responded asking for how this is a protocol 2392 change, he saw it as a clarification. Perhaps there is something 2393 deeper that needs to be clarified? Again, response to this is that 2394 current implementations allow the MinRouteAdvertisementInterval to be 2395 set per-peer, not per-router. 2397 Original reviewer conceded the point. 2399 There was some additional discussion on this point. Most of it was 2400 along the lines of extracting what was really implemented and 2401 supported among various vendors. The conclusion was the same. 2403 2.41. Mention FSM Internal Timers 2405 Status: Consensus 2406 Change: No 2407 Summary: No discussion on this issue. No text proposed. Perhaps 2408 this is in the FSM section of the draft? Either way, it defaults to 2409 consensus with no change. 2411 Discussion: 2413 7. P. 61, item 6.4. Although all the BGP protocol interfacing 2414 timers are mentioned, there are a few FSM internal timers mentioned 2415 in the spec that need to be covered here as well. 2417 There has been no discussion on this, it now defaults to consensus 2418 with no change. 2420 2.42. Delete the FSM Section 2422 Status: Consensus 2423 Change: No 2424 Summary: There was some confusion on the question: Is the FSM draft 2425 going to be a separate document, or incorporated into the base draft. 2426 The consensus is that it is going to become part of the base draft, 2427 so the FSM section will be kept, and elaborated on. 2429 Discussion: 2431 8. Since there is going to be an FSM spec, do we need to have FSM 2432 descriptions in this spec. Maybe the FSM section should be delete. 2434 There was one response agreeing with this. One response asking for 2435 clarification: Was this a move to remove section 8. Finite State 2436 Machine from the base draft?? The original reviewer said, yes, when 2437 Sue's FSM draft becomes a WG document, we should remove section 8 2438 from the base draft. Yakov asked that the AD's provide input on this 2439 suggestion. 2441 Alex responded saying that the FSM draft is going to be part of the 2442 base spec, and not another document once the FSM words are approved. 2444 2.43. Clarify the NOTIFICATION Section 2446 Status: Consensus 2447 Change: Yes 2448 Summary: Replace: 2450 "If a peer sends a NOTIFICATION message, and there is an error in 2451 that message, there is unfortunately no means of reporting this error 2452 via a subsequent NOTIFICATION message." 2454 With: 2456 If a peer sends a NOTIFICATION message, and the receiver of the 2457 message detects an error in that message, the receiver can not use a 2458 NOTIFICATION message to report this error back to the peer. 2460 Discussion: 2462 The "NOTIFICATION message error handling" thread proposed: 2464 Please change" "If a peer sends a NOTIFICATION message, and there is 2465 an error in that message, there is unfortunately no means of 2466 reporting this error via a subsequent NOTIFICATION message." 2468 To: "If a peer receives a NOTIFICATION message, and there is an error 2469 in that message, there is unfortunately no means of reporting this 2470 error via a subsequent NOTIFICATION message." 2472 This reversal of meaning met with disagreement, and this text was 2473 proposed instead: 2475 All errors detected while processing the NOTIFICATION message cannot 2476 be indicated by sending subsequent NOTIFICATION message back to 2477 originating peer, therefore there is no means of reporting 2478 NOTIFICATION message processing errors. Any error, such as an 2479 unrecognized Error Code or Error Subcode, should be noticed, logged 2480 locally, and brought to the attention of the administration of the 2481 peer that has sent the message. The means to do this, however, lies 2482 outside the scope of this document. 2484 The original posted agreed with the intent of the respondent's text, 2485 thought it was too wordy, but did not propose alternate text. 2487 Yakov replied with this proposed text: 2489 If a peer sends a NOTIFICATION message, and the receiver of the 2490 message detects an error in that message, the receiver can not use a 2491 NOTIFICATION message to report this error back to the peer. 2493 Two responses liked this new text. Unless there are objections, 2494 we'll consider that a consensus. 2496 2.44. Section 6.2: OPEN message error handling 2498 Status: Consensus 2499 Change: No 2500 Summary: One commenter observed that the spec seems to specify 2501 behavior that doesn't seem to be observed by extant implementations, 2502 and suggested modifications to the spec. They were later reminded 2503 that the base behavior is acceptable, and agreed. 2505 Discussion: 2507 The "BGP4 draft ; section 6.2" thread began with a discussion of 2508 section 6.2: OPEN message error handling. Specifically: 2510 "If one of the optional parameters in the Open message is not 2511 recognized, then the error subcode is set to 'unsupported optional 2512 parameters" 2513 We have hit on this line when we were testing a BGP connection 2514 between a speaker that supported capability negotiation and a speaker 2515 that did not. 2517 The speaker that did not support the negotiation closed down the 2518 peering session using the error clause mentioned above. Sometimes 2519 this lead to the other router to repeat the OPEN message with the 2520 Capability optional parameter; a game that went on for minutes. 2522 This router manufacturer stated in a reply to this that : "One should 2523 not close down the connection if an optional parameter is 2524 unrecognized. That would make this parameter basically mandatory. 2525 This is an well known error in the BGP spec. Neither Cisco or 2526 Juniper do this" 2528 If this is true it might be good to adapt the text. 2530 The response to this quoted RFC2842, Capabilities Advertisement with 2531 BGP-4: 2533 A BGP speaker determines that its peer doesn't support capabilities 2534 advertisement, if in response to an OPEN message that carries the 2535 Capabilities Optional Parameter, the speaker receives a NOTIFICATION 2536 message with the Error Subcode set to Unsupported Optional Parameter. 2537 In this case the speaker should attempt to re-establish a BGP 2538 connection with the peer without sending to the peer the Capabilities 2539 Optional Parameter. 2541 The original poster responded: 2543 This section from the Capabilities Advertisement RFC, is indeed 2544 inline with the section 6.2 of the BGP4 specification. For me 2545 however the question remains if most implementations do no simply 2546 ignore optional parameters that are unknown. And if so, if the text 2547 stated above reflects what is implemented by routers that do not have 2548 capability advertisement at all. 2550 Yakov replied to this with: 2552 RFC2842 assumes that a router (that doesn't implement RFC2842) would 2553 close the BGP session when the router receives an OPEN message with 2554 an unrecognized Optional Parameter. Therefore the text in the spec 2555 should be left unmodified. 2557 The original poster, Jonathan, agreed with this. This issue moves to 2558 consensus. 2560 2.45. Consistent References to BGP Peers/Connections/Sessions 2562 Status: Consensus 2563 Change: Yes 2564 Summary: Stick with "BGP Connection" as the consistent term. 2566 Discussion: 2568 Ben proposed and Yakov responded: 2570 > 1. Throughout the document we have various ways of naming the BGP 2571 > peering communication. 1) BGP Session, 2) BGP Peering Session, 2573 I'll replace "session" with "connection". 2575 > 3) TCP Connection, 2577 The spec doesn't name BGP peering communication as "TCP connection"; 2578 TCP connection is used to establish BGP connection. So, TCP 2579 connection and BGP connection are two different things. 2581 > 4) BGP Connection, 2583 The spec is going to use this term (see above). 2585 > 5) BGP Peering Connection, 2587 I'll replace "BGP peering connection" with "BGP connection". 2589 > 6) Connection, 2591 The text uses "connection" whenever it is clear from the context that 2592 it refers to "BGP connection" (or "TCP connection"). 2594 > 7) BGP Speaker Connection. 2596 I'll replace "BGP Speaker Connection" with "BGP connection". 2598 > > BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker 2600 The term "speaker" is used when it is clear from the context that we 2601 are talking about "BGP speaker". 2603 > 2. Change Internal peer to IBGP Peer. 2605 IBGP stands for "BGP connection between internal peers". Therefore 2606 the term "IBGP Peer" would mean "BGP connection between internal 2607 peers peer". That doesn't seem appropriate. 2609 This issue has had some discussion, and section 3 was referenced, 2610 specifically: 2612 Refer to Section 3 - Summary of operations which clearly states that 2613 " .. a peer in a different AS is referred to as an external peer, 2614 while a peer in the same AS may be described as an internal peer. 2615 Internal BGP and external BGP are commonly abbreviated IBGP and EBGP" 2617 After more discussion it was decided that we should modify a 2618 paragraph on page 4 to read: 2620 If a particular AS has multiple BGP speakers and is providing transit 2621 service for other ASs, then care must be taken to ensure a consistent 2622 view of routing within the AS. A consistent view of the interior 2623 routes of the AS is provided by the IGP used within the AS. For the 2624 purpose of this document, it is assumed that a consistent view of the 2625 routes exterior to the AS is provided by having all BGP speakers 2626 within the AS maintain IBGP with each other. Care must be taken to 2627 ensure that the interior routers have all been updated with transit 2628 information before the BGP speakers announce to other ASs that 2629 transit service is being provided. 2631 This change has consensus. 2633 > 3. Change External peer to EBGP Peer. 2635 Ditto. 2637 Alex responded that having explicit definitions would be nice. This 2638 ties into the general glossary suggestion (see issues 16, 34 & 36). 2640 He also suggested that: 2642 "BGP session" which works over a "TCP connection" would be closer to 2643 the terminology we're actually using now and would avoid possible 2644 confusions when people read terms like "Connection collision") 2646 This was discussed in the "Generial Editorial Comment" thread. 2648 After some further discussion, it was decided that, due to existing 2649 implementations, we should go with "BGP connection" as the consistent 2650 term. We are at consensus. 2652 2.46. FSM Connection Collision Detection 2654 Status: Consensus 2655 Change: Yes 2656 Summary: Add this to section 8: 2658 There is one FSM per connection. Prior to determining what peer a 2659 connection is associated with there may be two connections for a 2660 given peer. There should be no more than one connection per peer. 2661 The collision detection identifies the case where there is more than 2662 one connection per peer and provides guidance for which connection to 2663 get rid of. When this occurs, the corresponding FSM for the 2664 connection that is closed should be disposed of. 2666 Discussion: 2668 The original reviewer (Tom) commented that the base draft, FSM 2669 section, could use some clarification around the area of connection 2670 collision detection. Specifically, he argued that it seems like 2671 there are actually 2 FSM's depending on which one backs off in the 2672 case of a collision. He proposed this text to clear things up: 2674 "8 BGP Finite State Machine 2676 This section specifies BGP operation - between a BGP speaker and its 2677 peer over a single TCP connection - in terms of a Finite State 2678 Machine (FSM). Following is a brief summary ... "(as before) 2680 Instead of just 2682 "This section specifies BGP operation in terms of a Finite State 2683 Machine (FSM). Following is a brief summary ... "(as before). 2685 Curtis responded: 2687 There is one FSM per connection. Prior to determining what peer a 2688 connection is associated with there may be two connections for a 2689 given peer. There should be no more than one connection per peer. 2690 The collision detection identifies the case where there is more than 2691 one connection per peer and provides guidance for which connection to 2692 get rid of. When this occurs, the corresponding FSM for the 2693 connection that is closed should be disposed of. 2695 I'm not sure which document containing an FSM we should be reading at 2696 this point, but we could add the above paragraph if we need to 2697 explicitly state that the extra connection and its FSM is disposed of 2698 when a collision is detected. 2700 When a TCP accept occurs, a connection is created and an FSM is 2701 created. Prior to the point where the peer associated with the 2702 connection is known the FSM cannot be associated with a peer. The 2703 collision is a transient condition in which the rule of "one BGP 2704 session per peer" is temporarily violated and then corrected. 2706 This is discussed in the "FSM but FSM of what?" thread. 2708 Sue responded that she would be happy to add Curtis' text to section 2709 8 and solicited any additional comments. There was only one on 2710 capitalization, so this issue is at consensus. 2712 2.47. FSM - Add Explicit State Change Wording 2714 Status: Consensus 2715 Change: No 2716 Summary: A desire for explicit state change wording was expressed. 2717 No text was proposed. The assumption is that this issue has reached 2718 a happy conclusion. 2720 Discussion: 2722 The initial reviewer: 2724 In most places, the actions taken on the receipt of an event include 2725 what the new state will be or that it remains unchanged. But there 2726 are a significant number of places where this is not done (eg Connect 2727 state events 14, 15, 16). I would like to see consistency, always 2728 specify the new/unchanged state. Else I may be misreading it. 2730 There was a response asking for specific text, and offering to take 2731 the discussion private. 2733 This is discussed in the "FSM words - state changes" thread. 2735 There has been no further discussion on this. The assumption is that 2736 is has reached a happy conclusion privately. 2738 2.48. Explicitly Define Processing of Incoming Connections 2740 Status: Consensus 2741 Change: Yes 2742 Summary: Add text that is at the end of the discussion to section 8. 2744 Discussion: 2746 Alex suggested we explicitly define: 2748 - processing of incoming TCP connections (peer lookup, acceptance, 2749 FSM creation, collision control,) 2751 Curtis later proposed this text: 2753 BGP must maintain separate FSM for each configured peer. Each BGP 2754 peer paired in a potential connection will attempt to connect to the 2755 other. For the purpose of this discussions, the active or connect 2756 side of a TCP connection (the side sending the first TCP SYN packet) 2757 is called outgoing. The passive or listening side (the sender of the 2758 first SYN ACK) is called the an incoming connection. 2760 A BGP implementation must connect to and listen on TCP port 179 for 2761 incoming connections in addition to trying to connect to peers. For 2762 each incoming connection, a state machine must be instantiated. 2763 There exists a period in which the identity of the peer on the other 2764 end of an incoming connection is not known with certainty. During 2765 this time, both an incoming and outgoing connection for the same peer 2766 may exist. This is referred to as a connection collision (see 2767 Section x.x, was 6.8). 2769 A BGP implementation will have at most one FSM for each peer plus one 2770 FSM for each incoming TCP connection for which the peer has not yet 2771 been identified. Each FSM corresponds to exactly one TCP connection. 2773 Jonathan pointed out that there was an inaccuracy in the proposed 2774 text. Curtis replied with this: 2776 You're correct in that you must have a collision of IP addresses on 2777 the TCP connections and that the BGP Identifier is used only to 2778 resolve which gets dropped. 2780 The FSM stays around as long as "BGP Identifier" is not known. 2781 Replace "not known with certainty" with "known but the BGP identifier 2782 is not known" and replace "for the same peer" with "for the same 2783 configured peering". 2785 The first paragraph is unchanged: 2787 BGP must maintain separate FSM for each configured peer. Each BGP 2788 peer paired in a potential connection will attempt to connect to the 2789 other. For the purpose of this discussions, the active or connect 2790 side of a TCP connection (the side sending the first TCP SYN packet) 2791 is called outgoing. The passive or listening side (the sender of the 2792 first SYN ACK) is called the an incoming connection. 2794 The second paragraph becomes: 2796 A BGP implementation must connect to and listen on TCP port 179 for 2797 incoming connections in addition to trying to connect to peers. For 2798 each incoming connection, a state machine must be instantiated. 2799 There exists a period in which the identity of the peer on the other 2800 end of an incoming connection is known but the BGP identifier is not 2801 known. During this time, both an incoming and outgoing connection 2802 for the same configured peering may exist. This is referred to as a 2803 connection collision (see Section x.x, was 6.8). 2805 The next paragraph then needs to get fixed. Changed "for each peer" 2806 to "for each configured peering". 2808 A BGP implementation will have at most one FSM for each configured 2809 peering plus one FSM for each incoming TCP connection for which the 2810 peer has not yet been identified. Each FSM corresponds to exactly 2811 one TCP connection. 2813 Add a paragraph to further clarify the point you made. 2815 There may be more than one connection between a pair of peers if the 2816 connections are configured to use a different pair of IP addresses. 2817 This is referred to as multiple "configured peerings" to the same 2818 peer. 2820 > So multiple simultaneous BGP connection are allowed between the 2821 same two > peers, and this behavior is implemented, for example to do 2822 load balancing. 2824 Good point. 2826 I hope the corrections above cover your (entirely valid) objections. 2827 If you see any more errors please let me know. 2829 Tom replied that: 2831 I take issue with the 'will attempt to connect' which goes too far. 2833 The FSM defines events 4 and 5, 'with passive Transport 2834 establishment', so the system may wait and not attempt to connect. 2835 The exit from this state is either the receipt of an incoming TCP 2836 connection (SYN) or timer expiry. 2838 So we may have a FSM attempting to transport connect for a given 2839 source/destination IP pair or we may have an FSM not attempting to 2840 connect. (In the latter case, I do not think we can get a 2841 collision). In the latter case, an incoming connection should not 2842 generate an additional FSM. 2844 I do not believe the concept of active and passive is helpful since a 2845 given system can flip from one to the other and it does not help us 2846 to clarify the number of FSM involved.. 2848 And Curtis suggested that: 2850 Could this be corrected by replacing "will attempt to connect" with 2851 "unless configured to remain in the idle state, or configured to 2852 remain passive, will attempt to connect". We could also shorten that 2853 to "will attempt to connect unless configured otherwise". 2855 Clarification (perhaps an item for a glossary entry): The terms 2856 active and passive have been in our vocabulary for almost a decade 2857 and have proven useful. The words active and passive have slightly 2858 different meanings applied to a TCP connection or applied to a peer. 2859 There is only one active side and one passive side to any one TCP 2860 connection as per the definition below. When a BGP speaker is 2861 configured passive it will never attempt to connect. If a BGP 2862 speaker is configured active it may end up on either the active or 2863 passive side of the connection that eventually gets established. 2864 Once the TCP connection is completed, it doesn't matter which end was 2865 active and which end was passive and the only difference is which 2866 side of the TCP connection has port number 179. 2868 Tom agreed with Curtis, that he liked the "will attempt to connect 2869 unless configured otherwise" verbiage. 2871 This was discussed in the "Generial Editorial Comment" thread. 2873 Sue proposed we add the text above in section 8.2. It is summarized 2874 here for clarity: 2876 8.2) Description of FSM 2878 8.2.1) FSM connections 2880 (text below) 2882 8.2.2) FSM Definition 2884 (text now in 8.2) 2886 "BGP must maintain a separate FSM for each configured peer plus Each 2887 BGP peer paired in a potential connection unless configured to remain 2888 in the idle state, or configured to remain passive, will attempt to 2889 to connect to the other. For the purpose of this discussion, the 2890 active or connect side of the TCP connection (the side of a TCP 2891 connection (the side sending the first TCP SYN packet) is called 2892 outgoing. The passive or listening side (the sender of the first SYN 2893 ACK) is called an incoming connection. [See section on the terms 2894 active and passive below.] 2896 A BGP implementation must connect to and listen on TCP port 179 for 2897 incoming connections in addition to trying to connect to peers. Fro 2898 each incoming connection, a state machine must be instantiated. 2899 There exists a period in which the identity of the peer on the other 2900 end of an incoming connection is known but the BGP identifier is not 2901 known. During this time, both an incoming and an outgoing connection 2902 for the same configured peering may exist. This is referred to as a 2903 connection collision (see Section x.x, was 6.8). 2905 A BGP implementation will have at most one FSM for each configured 2906 peering plus one FSM for each incoming TCP connection for which the 2907 peer has not yet been identified. Each FSM corresponds to exactly 2908 one TCP connection. 2910 There may be more than one connections between a pair of peers if the 2911 connections are configured to use a different pair of IP addresses. 2912 This is referred to as multiple "configured peerings" to the same 2913 peer. 2915 8.2.1.1) Terms "active" and "passive" 2917 The terms active and passive have been in our vocabulary for almost a 2918 decade and have proven useful. The words active and passive have 2919 slightly different meanings applied to a TCP connection or applied to 2920 a peer. There is only one active side and one passive side to any 2921 one TCP connection per the definition above [and the state machine 2922 below.] When a BGP speaker is configured active it may end up on 2923 either the active or passive side of the connection that eventually 2924 gets established. Once the TCP connection is completed, it doesn't 2925 matter which end was active and which end was passive and the only 2926 difference is which side of the TCP connection has port number 179. 2928 For additional text, see issue 46. 2930 Sue solicited additional comments, the only one was on 2931 capitalization, so it would appear we are at consensus with this 2932 issue. 2934 2.49. Explicitly Define Event Generation 2936 Status: Consensus 2937 Change: No 2938 Summary: Suggested that we explicitly define BGP message processing. 2939 No text proposed. There has been no further discussion on this 2940 issue, it is assumed that the consensus is that things are ok the way 2941 they are. 2943 Discussion: 2945 Alex suggested we explicitly define: 2947 - generation of events while processing BGP messages, i.e., the text 2948 describing message processing should say where needed that a specific 2949 event for the BGP session should be generated. 2951 No text was proposed. 2953 This discussion has received no further comment. Unless someone 2954 wants to reopen it, it is assumed it has reached a happy ending. 2956 This was discussed in the "Generial Editorial Comment" thread. 2958 2.50. FSM Timers 2960 Status: Consensus 2961 Change: No 2962 Summary: Discussion tabled, because new document version rendered the 2963 discussion moot. 2965 Discussion: 2967 This discussion began with a suggestion that the timers currently in 2968 the FSM: 2970 In the 26 Aug text, I find the timer terminology still confusing. 2971 Timers can, I find, stop start restart clear set reset expire 2973 Can be cleaned up and simplified to: 2975 start with initial value (spell it out just to be sure) stop expire 2977 A response to this proposal was, that the existing set is clear, and 2978 that the proposed set is insufficiently rich to describe a concept 2979 like "reset" which encompasses: "Stop the timer, and reset it to its 2980 initial value." 2982 This discussion reached an impasse, when Sue pointed out that the 2983 text had been updated, and to please review the new text. 2985 This was discussed in the "FSM more words" thread. 2987 2.51. FSM ConnectRetryCnt 2989 Status: Consensus 2990 Change: No 2991 Summary: Discussion tabled, because new document version rendered the 2992 discussion moot. 2994 Discussion: 2996 This started with the observation that the ConnectRetryCnt "seems to 2997 have lost its purpose." It was suggested that this be made a Session 2998 Attribute, along with: OpenDelayTimer and DelayOpenFlag. 3000 Curtis explained that the current purpose of the ConnectRetryCnt is 3001 something to be read by the MIB. He also advocated against adding 3002 the additional Session Attributes. 3004 2.52. Section 3: Keeping routes in Adj-RIB-In 3006 Status: Consensus 3007 Change: Yes 3008 Summary: Add: To allow local policy changes to have the correct 3009 effect without resetting any BGP connections, a BGP speaker SHOULD 3010 either (a) retain the current version of the routes advertised to it 3011 by all of its peers for the duration of the connection, or (b) make 3012 use of the Route Refresh extension [12]. 3014 Discussion: 3016 This thread started with a question about why we should retain routes 3017 in the Adj-RIB-In, and how it relates to the Route Refresh extension. 3019 mrr proposed this text: 3021 ... Therefore, a BGP speaker must either retain the current version 3022 of the routes advertised by all of its peers for the duration of the 3023 connection, or make use of the Route Refresh extension [12]. This is 3024 necessary to allow local policy changes to have the correct effect 3025 without requiring the reset of any peering sessions. 3027 If the implementation decides not to retain the current version of 3028 the routes that have been received from a peer, then Route Refresh 3029 messages should be sent whenever there is a change to local policy. 3031 Yakov later suggested this text, with a slight rewording: 3033 To allow local policy changes to have the correct effect without 3034 resetting any BGP connections, a BGP speaker SHOULD either (a) retain 3035 the current version of the routes advertised to it by all of its 3036 peers for the duration of the connection, or (b) make use of the 3037 Route Refresh extension [12]. 3039 mrr responded that he was fine with Yakov's suggestions. 3041 This was discussed in the "Proxy: comments on section 3" thread. 3043 2.53. Section 4.3 - Routes v. Destinations - Advertise 3045 Status: Consensus 3046 Change: No 3047 Summary: The text that has reached consensus in issue 54 also 3048 addresses this issue. 3050 Discussion: 3052 This issue arose out of this question to the list: 3054 Since: 3056 "For the purpose of this protocol, a route is defined as a unit of 3057 information that pairs a set of destinations with the attributes of a 3058 path to those destinations. The set of destinations are the systems 3059 whose IP addresses are reported in the Network Layer Reachability 3060 Information (NLRI) field and the path is the information reported in 3061 the path attributes field of the same UPDATE message." 3063 When I read section 4.3: 3065 "An UPDATE message is used to advertise feasible routes sharing 3066 common path attribute to a peer, or to withdraw multiple unfeasible 3067 routes from service (see 3.1)." 3069 Shouldn't the text read "... advertise feasible [prefixes | 3070 destinations] sharing common path attribute(S)to a peer ...", 3071 because: 3073 1) A route is defined as quoted above from section 3.1? 3075 or since ... 3077 "An UPDATE message can advertise at most one set of path attributes, 3078 but multiple destinations ..." 3080 2) make "routes" in the original singular. 3082 This was discussed in the "Review Comments: Section 4.3: "routes" vs. 3083 destinations - advertise" thread. 3085 The text that has reached consensus in issue 54 also addresses this 3086 issue. 3088 2.54. Section 4.3 - Routes v. Destinations - Withdraw 3090 Status: Consensus 3091 Change: Yes 3092 Summary: Change the definition of "route" as it currently stands to: 3094 For the purpose of this protocol, a route is defined as a unit of 3095 information that pairs a set of destinations with the attributes of a 3096 path to those destinations. The set of destinations are systems 3097 whose IP addresses are contained in one IP address prefix carried in 3098 the Network Layer Reachability Information (NLRI) field of an UPDATE 3099 message and the path is the information reported in the path 3100 attributes field of the same UPDATE message. 3102 Multiple routes that have the same path attributes can be advertised 3103 in a single UPDATE message by including multiple prefixes in the NLRI 3104 field of the UPDATE message. 3106 Discussion: 3108 This issue was brought up with this question: 3110 When I read these two paragraphs at the end of section 4.3: 3112 "An UPDATE message can list multiple routes to be withdrawn from 3113 service. Each such route is identified by its destination (expressed 3114 as an IP prefix), which unambiguously identifies the route in the 3115 context of the BGP speaker - BGP speaker connection to which it has 3116 been previously advertised. 3118 An UPDATE message might advertise only routes to be withdrawn from 3119 service, in which case it will not include path attributes or Network 3120 Layer Reachability Information. Conversely, it may advertise only a 3121 feasible route, in which case the WITHDRAWN ROUTES field need not be 3122 present." 3124 It reads as if one must withdraw the _set of destinations_ advertised 3125 with the route instead of just one or more destinations since route 3126 is defined in section 3.1 as: 3128 "For the purpose of this protocol, a route is defined as a unit of 3129 information that pairs a set of destinations with the attributes of a 3130 path to those destinations. The set of destinations are the systems 3131 whose IP addresses are reported in the Network Layer Reachability 3132 Information (NLRI) field and the path is the information reported in 3133 the path attributes field of the same UPDATE message." 3135 Shouldn't the text change "routes" to destinations, or to prefixes? 3136 The original commenter added this clarification later: 3138 I meant to say, the *same* set of destinations as those advertised 3139 initially. For example, NLRI with dest-a, dest-b and dest-c with the 3140 same attributes is a "route". The withdrawal of the "route" can be 3141 read as one must withdraw all destinations originally advertised for 3142 that route (dest-a, dest-b, dest-c) as a unit. 3144 A first time reader could be left wondering if the above must be the 3145 case, or it is valid for an implementation to withdraw just one of 3146 these destinations (e.g. dest-b), leaving the others (dest-a, dest-c) 3147 reachable with their attributes intact. 3149 If there is no relationship between destinations when advertised as a 3150 set of destinations in a route and those destinations that can be 3151 withdrawn should be explicitly stated. Otherwise, the draft should 3152 call out that it is not legal to withdraw one prefix only in the set 3153 of prefixes advertised as previously as route. 3155 Matt suggested that since the definition seems to cause some 3156 confusion, that we update the definition to: 3158 "For the purpose of this protocol, a route is defined as a unit of 3159 information that pairs a set of destinations with the attributes of a 3160 path to those destinations. The set of destinations are systems 3161 whose IP addresses are reported in one prefix present in the Network 3162 Layer Reachability Information (NLRI) field of an UPDATE and the path 3163 is the information reported in the path attributes field of the same 3164 UPDATE message. 3166 This definition allows multiple routes to be advertised in a single 3167 UPDATE message by including multiple prefixes in the NLRI field of 3168 the UPDATE. All such prefixes must be associated with the same set 3169 of path attributes." 3171 Yakov suggested some minor rewording: 3173 For the purpose of this protocol, a route is defined as a unit of 3174 information that pairs a set of destinations with the attributes of a 3175 path to those destinations. The set of destinations are systems 3176 whose IP addresses are contained in one IP address prefix carried in 3177 the Network Layer Reachability Information (NLRI) field of an UPDATE 3178 message and the path is the information reported in the path 3179 attributes field of the same UPDATE message. 3181 Multiple routes that have the same path attributes can be advertised 3182 in a single UPDATE message by including multiple prefixes in the NLRI 3183 field of the UPDATE message. 3185 Both Jeff and Matt responded that they liked this text. 3187 2.55. Section 4.3 - Description of AS_PATH length 3189 Status: Consensus 3190 Change: Yes 3191 Summary: Replace: 3193 Path segment length is a 1-octet long field containing the number of 3194 ASs in the path segment value field. 3196 With: 3198 Path segment length is a 1-octet long field containing the number of 3199 ASs (not the number of octets) in the path segment value field. 3201 Discussion: 3203 This question was raised: 3205 Length fields elsewhere in the draft specify the number of bytes that 3206 a variable length field uses. For AS_PATH, length is used as the 3207 number of 2 byte AS numbers. In the interest of not having to check 3208 other sources to be sure, should the description of path segment 3209 value: 3211 "The path segment value field contains one or more AS numbers, each 3212 encoded as a 2-octets long field." 3214 explicitly mention the number of bytes used by the variable length 3215 field? 3217 Or, make the description of length explicitly mention that it is not 3218 the length of the variable length field as is the case with other 3219 length fields? 3221 One response to this agreed that some more clarification would be 3222 good, specifically an ASCII art diagram. No diagram was proposed. 3224 Yakov proposed this change: 3226 How about replacing 3228 Path segment length is a 1-octet long field containing the number of 3229 ASs in the path segment value field. 3231 with the following 3232 Path segment length is a 1-octet long field containing the number of 3233 ASs (but not the number of octets) in the path segment value field. 3235 Jonathan offered this text: 3237 How about: "Path segment length is a 1-octet long field containing 3238 the number of ASs (which is half the number of octets since each AS 3239 is 2 octets) in the path segment value field (also note that the path 3240 may contain more than 1 segment). 3242 Jeff replied that he preferred Yakov's text, but without the "but". 3243 Yakov agreed to that. Andrew also agreed, and asked if there were 3244 any objections to moving this issue into consensus. There were no 3245 objections. 3247 2.56. Section 6 - BGP Error Handling 3249 Status: Consensus 3250 Change: Yes 3251 Summary: There are a variety of updates to the text that are best 3252 described in the discussion section. 3254 Discussion: 3256 This discussion began with some suggestions on ways to clarify the 3257 text in section 6 dealing with error handling. The original 3258 comments, and Yakov's response are below: 3260 > At the beginning of Section 6. BGP Error Handling: 3261 > 3262 > 3263 > "When any of the conditions described here are detected, a 3264 > NOTIFICATION message with the indicated Error Code, Error Subcode, 3265 > and Data fields is sent, and the BGP connection is closed." 3266 > 3267 > There are several cases where the conditions described in this 3268 section 3269 > do not result in the BGP connection being closed. These conditions 3270 > should either state that the connection stays up. Another 3271 possibility 3272 > is to remove "and the BGP connection is closed." above, and for 3273 each 3274 > listed connection, state what happens to the BGP connection. This 3275 > already takes place for certain conditions, but isn't done 3276 consistently. 3278 How about replacing the above with the following: 3280 When any of the conditions described here are detected, a 3281 NOTIFICATION message with the indicated Error Code, Error Subcode, 3282 and Data fields is sent, and the BGP connection is closed, unless it 3283 is explicitly stated that no NOTIFICATION message is to be sent and 3284 the BGP connection is not to be close. 3286 > I tried to list what I found (which may be wrong or incomplete) 3287 below: 3288 > 3289 > 3290 > "If the NEXT_HOP attribute is semantically incorrect, the error 3291 should 3292 > be logged, and the route should be ignored. In this case, no 3293 > NOTIFICATION message should be sent." 3294 > 3295 > * Append the connection is not closed. 3297 Done. 3299 > 3300 > "(a) discard new address prefixes from the neighbor, or (b) 3301 terminate 3302 > the BGP peering with the neighbor." 3303 > 3304 > * Append "the connection is not closed" to case (a) 3306 added "(while maintaining BGP peering with the neighbor)" to case 3307 (a). 3309 > 3310 > "If the autonomous system number appears in the AS path the 3311 > route may be stored in the Adj-RIB-In," 3312 > 3313 > * append and the BGP connection stays up. 3314 > 3315 > "but unless the router is configured to accept routes with its 3316 > own autonomous system in the AS path, the route shall not be 3317 > passed to the BGP Decision Process." 3319 I would suggest to move this text to Section 9 (UPDATE message 3320 handling), as receiving a route with your own AS in the AS path isn't 3321 really an error. It is just that usually (but not always) you can't 3322 put this route in your Adj-RIB-In. 3324 > * Q1) does the BGP connection stay up? 3326 yes. 3328 > * Q2) what if the router isn't configured to accept routes with its 3329 > own AS in the AS path? One _may_ store the route in Adj-RIB-In, 3330 but 3331 > if one doesn't want to? 3333 So, don't store them. 3335 > Is the BGP connection closed? If so, what subcode? 3337 The connection is *not* closed. 3339 > "If an optional attribute is recognized, then the value of this 3340 > attribute is checked. If an error is detected, the attribute is 3341 > discarded, and the Error Subcode is set to Optional Attribute 3342 Error. 3343 > The Data field contains the attribute (type, length and value)." 3344 > 3345 > * Append and the BGP connection stays up after "the attribute is 3346 discarded". 3348 Since you have to close the connection, you have to discard all the 3349 routes received via this connection, including the route with the 3350 incorrect attribute. So, there is no need to say that "the attribute 3351 is discarded". 3353 There have been no objections to the updates listed above. This 3354 issue seems to have reached a happy ending, so it has been moved into 3355 consensus. 3357 This was discussed in the "-17 review Section 6 - BGP Error 3358 Handling." thread. 3360 2.57. Section 6.2 - Hold timer as Zero 3362 Status: Consensus 3363 Change: No 3364 Summary: It was suggested that we update the text to say that we MUST 3365 reject hold time values of zero. It was pointed out that this is not 3366 the case and the text should say the way it is. 3368 Discussion: 3370 In Section 6.2 on OPEN message error handling: 3372 If the Hold Time field of the OPEN message is unacceptable, then the 3373 Error Subcode MUST be set to Unacceptable Hold Time. An 3374 implementation MUST reject Hold Time values of one or two seconds. 3376 I feel that text similar to: 3378 "An implementation MUST also reject Hold Time values of zero received 3379 from a peer in a different AS" should be considered for completeness. 3381 A number of respondents pointed out that zero hold time is legitimate 3382 under certain circumstances. 3384 This was discussed in the "-17 review, Section 6.2 - must reject hold 3385 time" thread. 3387 2.58. Deprecation of ATOMIC_AGGREGATE 3389 Status: Consensus 3390 Change: Yes 3391 Summary: For new text, please see the end of the discussion. 3393 Discussion: 3395 Jeff opened this discussion with: 3397 Deprecation of ATOMIC_AGGREGATE: 3399 [This is a summary of some discussions from those who have "been 3400 there, done that" during the CIDR deployment period and also comments 3401 from network operators on the NANOG list.] 3403 When BGP-4 was originally drafted, the topic of aggregation was new 3404 enough that people didn't exactly know how it would be used. 3405 Additionally, there were some transition issues when aggregated 3406 networks would need to be de-aggregated and re-advertised into a 3407 classful routing mesh such as BGP-3. 3409 The ATOMIC_AGGREGATE flag was intended to prevent a route from being 3410 de-aggregated when de-aggregation would introduce routing loops. 3411 Note that de-aggregation in this context specifically means making a 3412 less specific route into one or more more-specific routes. 3414 The current BGP draft has two situations where ATOMIC_AGGREGATE 3415 should be appended to a route: 1. When a route's AS_PATH is 3416 intentionally truncated, such as what happens by default on Cisco's, 3417 or using the "brief" option on GateD. Juniper has a similar feature 3418 - I'm unsure of the default. 2. When two routes are implicitly 3419 aggregated in the LocRib such that a more specific route is not 3420 selected when a less specific route is from a given peer. 3422 Note that this particular feature is not implemented anywhere that I 3423 am aware of. 3425 3. There is a third case not covered by the specification: Implicit 3426 aggregation on export - a more specific route is not exported and 3427 only a less specific one is. 3429 When network operators were asked about de-aggregation practices, I 3430 received about 40 responses. The majority of these responses 3431 confused de-aggregation with leaking existing more-specific routes 3432 that are used internally rather than explicitly de-aggregating a 3433 less-specific route. 3435 There were a very few cases of explicit de-aggregation. One form was 3436 done for purposes of dealing with another ISP creating a routing DoS 3437 by advertising IP space that didn't belong to them - leaked more 3438 specifics alleviated the problem in many cases. (Note that this is a 3439 security issue in the routing system.) 3441 The second case was de-aggregating routes internally (and sending the 3442 routes via IBGP marked with NO-ADVERTISE) for purposes of traffic 3443 engineering routing internally where a given upstream failed to 3444 provide enough routing information to allow traffic flows to be 3445 optimized based on supplied prefixes. 3447 My conclusions to this are: 1. De-aggregation is not a common 3448 practice. 2. It is no longer a major concern since classful inter- 3449 domain routing is pretty much gone. 3. The spec doesn't match 3450 reality and should be corrected. 3452 My suggestions are thus this: Section 5.1.6 should be updated as 3453 follows: ATOMIC_AGGREGATE is a well-known discretionary attribute. 3454 Its use is deprecated. 3456 When a router explicitly aggregates several routes for the purpose of 3457 advertisement to a particular peer, and the AS_PATH of the aggregated 3458 route excludes at least some of the AS numbers present in the AS_PATH 3459 of the routes that are aggregated (usually due to truncation), the 3460 aggregated route, when advertised to the peer, MUST include the 3461 ATOMIC_AGGREGATE attribute. 3463 Section 9.1.4 should be updated as follows: 3464 Original text: If a BGP speaker receives overlapping routes, the 3465 Decision Process MUST consider both routes based on the configured 3466 acceptance policy. If both a less and a more specific route are 3467 accepted, then the Decision Process MUST either install both the less 3468 and the more specific routes or it MUST aggregate the two routes and 3469 install the aggregated route, provided that both routes have the same 3470 value of the NEXT_HOP attribute. 3472 If a BGP speaker chooses to aggregate, then it MUST add 3473 ATOMIC_AGGREGATE attribute to the route. A route that carries 3474 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3475 NLRI of this route can not be made more specific. Forwarding along 3476 such a route does not guarantee that IP packets will actually 3477 traverse only ASs listed in the AS_PATH attribute of the route. 3479 Replace with: 3481 It is common practice that more specific routes are often implicitly 3482 aggregated by selecting or advertising only a less-specific route 3483 when overlapping routes are present. As such, all routes SHOULD be 3484 treated as if ATOMIC_AGGREGATE is present and not be made more 3485 specific (de-aggregated). De-aggregation may lead to routing loops. 3487 Section 9.2.2 should remain as it is. 3489 Implications of not making the above updates: 3490 ATOMIC_AGGREGATE is not implemented as documented. Current 3491 operational practices do not seem to often trigger situations that it 3492 was intended to re-mediate. After all, by the way it is currently 3493 documented, many of the routes in the Internet would likely have 3494 ATOMIC_AGGREGATE. 3496 The original motivation for this investigation (aside from a few 3497 years of wondering what this portion of the spec *really* meant) was 3498 making sure the MIB is correctly documented. I can do this now, even 3499 if the spec is not corrected by simply noting that the values: 3500 lessSpecificRouteNotSelected(1), 3501 lessSpecificRouteSelected(2) 3503 mean: 3504 ATOMIC_AGGREGATE not present 3505 ATOMIC_AGGREGATE present 3507 rather than documenting anything about less and more specific routes. 3509 The v2MIB can be fixed to just call it what it is since it hasn't 3510 been RFC'ed yet. 3512 Lastly, the spec would just be incorrect. But all said, nothing bad 3513 would really come of this. 3515 Yakov responded to this, saying that he thought these changes were 3516 reasonable, and unless there were objections, they would be adopted. 3518 Ishi strongly agreed with the changes. 3520 Curtis stated that: 3522 We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated 3523 rather than replaced with an AS_SET. It was always purely 3524 informational since no one intentionally deaggregated and 3525 reannounced. 3527 And suggested that we remove the MUSTs and indicated that this is 3528 only informational. 3530 Jeff replied that: 3532 The point is that by definition of the attribute, anywhere that 3533 policy is used (and some places where it may not be), 3534 ATOMIC_AGGREGATE *should* be there. Since its not, and it would 3535 generally be everywhere, you just shouldn't de-aggregate. 3537 At best, leaving it as a method of informationally signalling 3538 truncation of a AS_PATH is the best we'll get out of it - and it 3539 matches current implementations. 3541 Jonathan agreed with Curtis' idea that we should just move 3542 ATOMIC_AGGREGATE to informational. 3544 Curtis proposed this text: 3546 This existing text is fine: 3548 f) ATOMIC_AGGREGATE (Type Code 6) 3550 ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0. 3551 Usage of this attribute is described in 5.1.6. 3553 This is the existing text that we are considering changing: 3555 5.1.6 ATOMIC_AGGREGATE 3557 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3559 When a router aggregates several routes for the purpose of 3560 advertisement to a particular peer, and the AS_PATH of the aggregated 3561 route excludes at least some of the AS numbers present in the AS_PATH 3562 of the routes that are aggregated, the aggregated route, when 3563 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3565 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3566 attribute MUST NOT remove the attribute from the route when 3567 propagating it to other speakers. 3569 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3570 attribute MUST NOT make any NLRI of that route more specific (as 3571 defined in 9.1.4) when advertising this route to other BGP speakers. 3573 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3574 attribute needs to be cognizant of the fact that the actual path to 3575 destinations, as specified in the NLRI of the route, while having the 3576 loop-free property, may not be the path specified in the AS_PATH 3577 attribute of the route. 3579 Suggested new text: 3581 5.1.6 ATOMIC_AGGREGATE 3583 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3585 When a router aggregates several routes for the purpose of 3586 advertisement to a particular peer, the AS_PATH of the aggregated 3587 route normally includes an AS_SET formed from the set of AS from 3588 which the aggregate was formed. In many cases the network 3589 administrator can determine that the aggregate can safely be 3590 advertised without the AS_SET and not form route loops. 3592 If an aggregate excludes at least some of the AS numbers present in 3593 the AS_PATH of the routes that are aggregated as a result of dropping 3594 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3595 include the ATOMIC_AGGREGATE attribute. 3597 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3598 attribute SHOULD NOT remove the attribute from the route when 3599 propagating it to other speakers. 3601 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3602 attribute MUST NOT make any NLRI of that route more specific (as 3603 defined in 9.1.4) when advertising this route to other BGP speakers. 3605 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3606 attribute needs to be cognizant of the fact that the actual path to 3607 destinations, as specified in the NLRI of the route, while having the 3608 loop-free property, may not be the path specified in the AS_PATH 3609 attribute of the route. 3611 Diffs (for reader convenience): 3613 @@ -4,13 +4,19 @@ ATOMIC_AGGREGATE is a well-known discretionary 3614 attribute. 3616 When a router aggregates several routes for the purpose of 3617 - advertisement to a particular peer, and the AS_PATH of the 3618 - aggregated route excludes at least some of the AS numbers 3619 - present in the AS_PATH of the routes that are aggregated, 3620 - the aggregated route, when advertised to the peer, MUST 3621 - include the ATOMIC_AGGREGATE attribute. 3622 + advertisement to a particular peer, the AS_PATH of the 3623 + aggregated route normally includes an AS_SET formed from the 3624 + set of AS from which the aggregate was formed. In many cases 3625 + the network administrator can determine that the aggregate can 3626 + safely be advertised without the AS_SET and not form route loops. 3627 + 3628 + If an aggregate excludes at least some of the AS numbers present 3629 + in the AS_PATH of the routes that are aggregated as a result of 3630 + dropping the AS_SET, the aggregated route, when advertised to the 3631 + peer, SHOULD include the ATOMIC_AGGREGATE attribute. 3633 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3634 - attribute MUST NOT remove the attribute from the route when 3635 + attribute SHOULD NOT remove the attribute from the route when 3636 + propagating it to other speakers. 3638 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3640 Current text in 9.1.4: 3642 If a BGP speaker chooses to aggregate, then it MUST add 3643 ATOMIC_AGGREGATE attribute to the route. A route that carries 3644 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3645 NLRI of this route can not be made more specific. Forwarding along 3646 such a route does not guarantee that IP packets will actually 3647 traverse only ASs listed in the AS_PATH attribute of the route. 3649 Change to: 3651 If a BGP speaker chooses to aggregate, then it SHOULD either include 3652 all AS used to form the aggregate in an AS_SET or add the 3653 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3654 primarily informational. With the elimination of IP routing 3655 protocols that do not support classless routing and the elimination 3656 of router and host implementations that do not support classless 3657 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3658 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3659 particular MUST NOT be de-aggregated. That is, the NLRI of this 3660 route can not be made more specific. Forwarding along such a route 3661 does not guarantee that IP packets will actually traverse only ASs 3662 listed in the AS_PATH attribute of the route. 3664 This text in 9.2.2.2 need not change. 3666 ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has 3667 ATOMIC_AGGREGATE path attribute, then the aggregated route shall have 3668 this attribute as well. 3670 The appendix need not change: 3672 Appendix 1. Comparison with RFC1771 3674 [...] 3676 Clarifications to the use of the ATOMIC_AGGREGATE attribute. 3678 This might be a bit more wordy that is necessary. It does address 3679 the objections to keeping ATOMIC_AGGREGATE by making the MUST into 3680 SHOULD, and explaining that ATOMIC_AGGREGATE is now primarily 3681 informational. 3683 Yakov was fine with this text. 3685 Yakov posted the text that represents the WG consensus: 3687 Replace: 3689 5.1.6 ATOMIC_AGGREGATE 3691 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3693 When a router aggregates several routes for the purpose of 3694 advertisement to a particular peer, and the AS_PATH of the aggregated 3695 route excludes at least some of the AS numbers present in the AS_PATH 3696 of the routes that are aggregated, the aggregated route, when 3697 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3699 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3700 attribute MUST NOT remove the attribute from the route when 3701 propagating it to other speakers. 3703 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3704 attribute MUST NOT make any NLRI of that route more specific (as 3705 defined in 9.1.4) when advertising this route to other BGP speakers. 3707 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3708 attribute needs to be cognizant of the fact that the actual path to 3709 destinations, as specified in the NLRI of the route, while having the 3710 loop-free property, may not be the path specified in the AS_PATH 3711 attribute of the route. 3713 with: 3715 5.1.6 ATOMIC_AGGREGATE 3717 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3719 When a router aggregates several routes for the purpose of 3720 advertisement to a particular peer, the AS_PATH of the aggregated 3721 route normally includes an AS_SET formed from the set of AS from 3722 which the aggregate was formed. In many cases the network 3723 administrator can determine that the aggregate can safely be 3724 advertised without the AS_SET and not form route loops. 3726 If an aggregate excludes at least some of the AS numbers present in 3727 the AS_PATH of the routes that are aggregated as a result of dropping 3728 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3729 include the ATOMIC_AGGREGATE attribute. 3731 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3732 attribute SHOULD NOT remove the attribute from the route when 3733 propagating it to other speakers. 3735 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3736 attribute MUST NOT make any NLRI of that route more specific (as 3737 defined in 9.1.4) when advertising this route to other BGP speakers. 3739 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3740 attribute needs to be cognizant of the fact that the actual path to 3741 destinations, as specified in the NLRI of the route, while having the 3742 loop-free property, may not be the path specified in the AS_PATH 3743 attribute of the route. 3745 In 9.1.4 replace: 3747 If a BGP speaker chooses to aggregate, then it MUST add 3748 ATOMIC_AGGREGATE attribute to the route. A route that carries 3749 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3750 NLRI of this route can not be made more specific. Forwarding along 3751 such a route does not guarantee that IP packets will actually 3752 traverse only ASs listed in the AS_PATH attribute of the route. 3754 with: 3756 If a BGP speaker chooses to aggregate, then it SHOULD either include 3757 all AS used to form the aggregate in an AS_SET or add the 3758 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3759 primarily informational. With the elimination of IP routing 3760 protocols that do not support classless routing and the elimination 3761 of router and host implementations that do not support classless 3762 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3763 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3764 particular MUST NOT be de-aggregated. That is, the NLRI of this 3765 route can not be made more specific. Forwarding along such a route 3766 does not guarantee that IP packets will actually traverse only ASs 3767 listed in the AS_PATH attribute of the route. 3769 This met with agreement. This issue is at consensus. 3771 2.59. Section 4.3 - Move text 3773 Status: Consensus 3774 Change: Yes (minimal) 3775 Summary: Update indentation to allow a new "subsection" heading. 3776 Otherwise no change. 3778 Discussion: 3780 This began with this suggestion: 3782 The text about the minimum length, at first look, gives the 3783 impression that it is still part of the NLRI field description and/or 3784 the Path Attributes section. A new "subsection" or heading of some 3785 sort would be helpful in switching context back to the UPDATE message 3786 as a whole and not the path attributes field anymore. 3788 Yakov agreed to update the indentation. 3790 Jonathan agreed, and suggested this text: 3792 " The minimum length of the UPDATE message is 23 octets -- 19 octets 3793 for the fixed header + 2 octets for the Withdrawn Routes Length + 2 3794 octets for the Total Path Attribute Length (the value of Withdrawn 3795 Routes Length is 0 and the value of Total Path Attribute Length is 3796 0)." 3798 Should be moved up to just after 3800 "... the Total Path Attribute Length field and the Withdrawn Routes 3801 Length field." 3803 Yakov responded to this with: 3805 Disagree, as "... the Total Path Attribute Length field and the 3806 Withdrawn Routes Length field." explains how to calculate the length 3807 of NLRI field (and therefore is part of the NLRI field description), 3808 while "The minimum length of the UPDATE message is 23 octets...." has 3809 to do with the length of the UPDATE message. 3811 Jonathan also suggested: 3813 " the value of Withdrawn Routes Length is 0 and the value of Total 3814 Path Attribute Length is 0)." 3816 Should be changed to 3818 " the min. value of Withdrawn Routes Length is 0 and the min. value 3819 of Total Path Attribute Length is 0)." 3821 And Yakov responded with: 3823 Disagree, as the text doesn't talk about what is the minimum value of 3824 the Withdrawn Routes Length and Total Path Attribute Length fields, 3825 but talks about the value of these fields in the case of a min length 3826 UPDATE message. 3828 After Yakov's response and a posting to the list asking that this be 3829 moved to consensus, there were no objections, so this is moved to 3830 consensus. 3832 This is discussed in the "Review: Comments: Section 4.3: UPDATE min 3833 length" thread. 3835 2.60. Section 4.3 - Path Attributes 3837 Status: Consensus 3838 Change: Yes 3839 Summary: Make this change to clarify path attributes in an UPDATE: 3841 To correct the confusion I propose to replace: 3843 A variable length sequence of path attributes is present in every 3844 UPDATE. 3846 with: 3848 A variable length sequence of path attributes is present in every 3849 UPDATE message, except for an UPDATE message that carries only the 3850 withdrawn routes. 3852 Discussion: 3854 This thread began with MikeC pointing out: 3856 The top of page 13 says: 3858 "A variable length sequence of path attributes is present in every 3859 UPDATE." 3861 Is this really true, given that later, in the second to last 3862 paragraph of this section (4.3): 3864 "An UPDATE message might advertise only routes to be withdrawn from 3865 service, in which case it will not include path attributes or Network 3866 Layer Reachability Information." 3868 This could be confusing to a first time reader. 3870 The path attribute length is present in every UPDATE, the path 3871 attribute field itself can be left out, both according to the 3872 description of the minimum length of the UPDATE message and 3873 (implied?) in the picture of the UPDATE message at the beginning of 3874 section 4.3. 3876 This met with one agreement. 3878 Yakov then proposed that: 3880 To correct the confusion I propose to replace: 3882 A variable length sequence of path attributes is present in every 3883 UPDATE. 3885 with: 3887 A variable length sequence of path attributes is present in every 3888 UPDATE message, except for an UPDATE message that carries only the 3889 withdrawn routes. 3891 There was one agreement with this proposal. 3893 This is discussed in the thread: "Review: Section 4.3 - Path 3894 Attributes" 3896 2.61. Next Hop for Redistributed Routes 3898 Status: Consensus 3899 Change: Yes 3900 Summary: More clearly specify the behavior of NEXT_HOP modification, 3901 for the text see the end of the discussion. 3903 Discussion: 3905 Jonathan began this thread with: 3907 I propose adding: 3909 "When announcing a locally originated route to an internal peer, the 3910 BGP speaker should use as the NEXT_HOP the interface address of the 3911 router through which the announced network is reachable for the 3912 speaker; if the route is directly connected to the speaker, or the 3913 interface address of the router through which the announced network 3914 is reachable for the speaker is the internal peer's address, then the 3915 BGP speaker should use for the NEXT_HOP attribute its own IP address 3916 (the address of the interface that is used to reach the peer)." 3918 AFTER 3920 "When sending a message to an internal peer, the BGP speaker should 3921 not modify the NEXT_HOP attribute, unless it has been explicitly 3922 configured to announce its own IP address as the NEXT_HOP." 3924 There has been no discussion on this. 3926 This is discussed in the "Next hop for redistributed routes" thread. 3928 Issue 14 closed in favor of this issue. 3930 In response to Yakov's call for input, Michael responded that: 3932 Section 5.1.3 explicitly states what to do when originating to an 3933 external peer. #2 covers one hop away, #3 covers more than on hop 3934 away. #1 talks about sending to an iBGP peer, but only when 3935 propagating a route received from an eBGP peer. 3937 1) When sending a message to an internal peer, the BGP speaker should 3938 not modify the NEXT_HOP attribute, unless it has been explicitly 3939 configured to announce its own IP address as the NEXT_HOP. 3941 Text similar to #2 should be added, in their own bullet items to #1 3942 such as what was suggested by Jonathan Natale (text is above.) 3944 Yakov replied with this: 3946 Replace: 3948 1) When sending a message to an internal peer, the BGP speaker should 3949 not modify the NEXT_HOP attribute, unless it has been explicitly 3950 configured to announce its own IP address as the NEXT_HOP. 3952 with: 3954 1) When sending a message to an internal peer, if the route is not 3955 locally originated the BGP speaker should not modify the NEXT_HOP 3956 attribute, unless it has been explicitly configured to announce its 3957 own IP address as the NEXT_HOP. When announcing a locally originated 3958 route to an internal peer, the BGP speaker should use as the NEXT_HOP 3959 the interface address of the router through which the announced 3960 network is reachable for the speaker; if the route is directly 3961 connected to the speaker, or the interface address of the router 3962 through which the announced network is reachable for the speaker is 3963 the internal peer's address, then the BGP speaker should use for the 3964 NEXT_HOP attribute its own IP address (the address of the interface 3965 that is used to reach the peer). 3967 And stated the change would be made if there were no objections. 3968 There have been no objections, so this is at consensus. 3970 2.62. Deprecate BGP Authentication Optional Parameter from RFC1771 3972 Status: Consensus 3973 Change: Yes 3974 Summary: We are at consensus, in that we agree that we should 3975 deprecate the BGP Authentication Optional Parameter as described in 3976 RFC1771 in favor of the mechanism described in RFC2385. The textual 3977 changes are listed at the end of the discussion section of this 3978 issue. 3980 Discussion: 3982 This discussion started in issue 21: Authentication Text Update. 3984 This topic has come up before (July time frame), but was recently 3985 refreshed in the context of issue 21. It began with some questions 3986 to the list as to who used what sort of authentication mechanisms. 3987 From the responses it was clear that MD5 (RFC2385) was the preferred 3988 method. 3990 Eric Gray's message helps to flesh this out: 3992 The question is not whether MD5 authentication is used, it is how is 3993 it implemented in real BGP implementations or - more importantly - 3994 where is the authentication information located in the packets sent 3995 between two BGP peers? This is not strictly an implementation issue 3996 because authentication information is located in different places 3997 depending on which version of MD5 authentication is in use. 3999 As is generally known, options are not necessarily good. Currently, 4000 between RFC 1771 and RFC 2385, there are two very distinct ways to 4001 accomplish a semantically identical function. If the mechanism 4002 defined in RFC 1771 is not supported by a number of interoperable 4003 implementations, it must be deprecated per RFC 2026 prior to 4004 advancing the specification to Draft Standard. If it is not 4005 implemented and actually in use, it should be deprecated if for no 4006 other reason than to make the 4008 To this Yakov responded: 4010 To be more precise, 4012 In cases in which one or more options or features have not been 4013 demonstrated in at least two interoperable implementations, the 4014 specification may advance to the Draft Standard level only if those 4015 options or features are removed. 4017 So, the relevant question is whether we have at least two 4018 implementations that support authentication as described in rfc1771. 4020 Folks who implemented authentication, as described in rfc1771, please 4021 speak up. 4023 There have been no responses to Yakov's question. 4025 There seems to be a consensus that, since it is little used, and 4026 since there are better mechanisms, namely MD5 authentication, we 4027 should deprecate the BGP Authentication Optional Parameter from 4028 RFC1771. 4030 Ok, after some discussion, this is a list of the text that we are 4031 adding, changing or removing: 4033 1) Remove the reference to the authentication optional parameter: 4035 I would suggest to remove the following text from the draft: 4037 This document defines the following Optional Parameters: 4039 a) Authentication Information (Parameter Type 1): 4041 This optional parameter may be used to authenticate a BGP peer. The 4042 Parameter Value field contains a 1-octet Authentication Code followed 4043 by a variable length Authentication Data. 4045 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | Auth. Code | 4046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 4047 Authentication Data | | | 4048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4050 Authentication Code: 4052 This 1-octet unsigned integer indicates the authentication mechanism 4053 being used. Whenever an authentication mechanism is specified for 4054 use within BGP, three things must be included in the specification: 4056 - the value of the Authentication Code which indicates use of the 4057 mechanism, - the form and meaning of the Authentication Data, and - 4058 the algorithm for computing values of Marker fields. 4060 Note that a separate authentication mechanism may be used in 4061 establishing the transport level connection. 4063 Authentication Data: 4065 Authentication Data is a variable length field that is interpreted 4066 according to the value of the Authentication Code field. 4068 2) Update the introduction: 4070 In section 2 (Introduction), sixth paragraph 4072 From: 4074 BGP runs over a reliable transport protocol. This eliminates the 4075 need to implement explicit update fragmentation, retransmission, 4076 acknowledgment, and sequencing. Any authentication scheme used by 4077 the transport protocol (e.g., RFC2385 [10]) may be used in addition 4078 to BGP's own authentication mechanisms. The error notification 4079 mechanism used in BGP assumes that the transport protocol supports a 4080 "graceful" close, i.e., that all outstanding data will be delivered 4081 before the connection is closed. 4083 To: 4085 BGP uses TCP [RFC793] as its transport protocol. This eliminates the 4086 need to implement explicit update fragmentation, retransmission, 4087 acknowledgment, and sequencing. BGP listens on TCP port 179. Any 4088 authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be 4089 used. The error notification mechanism used in BGP assumes that TCP 4090 supports a "graceful" close, i.e., that all outstanding data will be 4091 delivered before the connection is closed. 4093 3) Update the message header format section: 4095 From: 4097 Marker: 4099 This 16-octet field contains a value that the receiver of the message 4100 can predict. If the Type of the message is OPEN, or if the OPEN 4101 message carries no Authentication Information (as an Optional 4102 Parameter), then the Marker must be all ones. Otherwise, the value 4103 of the marker can be predicted by some a computation specified as 4104 part of the authentication mechanism (which is specified as part of 4105 the Authentication Information) used. The Marker can be used to 4106 detect loss of synchronization between a pair of BGP peers, and to 4107 authenticate incoming BGP messages. 4109 To: 4111 Marker: 4113 This 16-octet field is included for compatibility; it must be set to 4114 all ones. 4116 4) Update the Message Header error handling section: 4118 In section 6.1 (Message Header error handling), second paragraph 4120 From: 4122 The expected value of the Marker field of the message header is all 4123 ones if the message type is OPEN. The expected value of the Marker 4124 field for all other types of BGP messages determined based on the 4125 presence of the Authentication Information Optional Parameter in the 4126 BGP OPEN message and the actual authentication mechanism (if the 4127 Authentication Information in the BGP OPEN message is present). If 4128 the Marker field of the message header is not the expected one, then 4129 a synchronization error has occurred and the Error Subcode is set to 4130 Connection Not Synchronized. 4132 To: 4134 The expected value of the Marker field of the message header is all 4135 ones. If the Marker field of the message header is not as expected, 4136 then a synchronization error has occurred and the Error Subcode is 4137 set to Connection Not Synchronized. 4139 5) Remove a paragraph from the OPEN message error handling section 4140 (section 6.2): 4142 If the OPEN message carries Authentication Information (as an 4143 Optional Parameter), then the corresponding authentication procedure 4144 is invoked. If the authentication procedure (based on Authentication 4145 Code and Authentication Data) fails, then the Error Subcode is set to 4146 Authentication Failure. 4148 6) Update the "Differences from RFC1771 Appendix" 4150 Text not listed here 4152 7) Fix the hole in the numbering by updating: 4154 From: 4156 This document defines the following Optional Parameters: 4158 a) Authentication Information (Parameter Type 1): 4160 To: 4162 This document defines the following Optional Parameters: 4164 a) Optional parameter type 1, Authentication Information, has been 4165 deprecated. 4167 We are at consensus with these changes. 4169 2.63. Clarify MED Removal Text 4171 Status: Consensus 4172 Change: Yes 4173 Summary: Modify text to clear up MED removal behavior. Text is at 4174 the end of the discussion. 4176 Discussion: 4178 This discussion began when Jonathan posted a question to the list: 4180 In reference to: 4182 "A BGP speaker MUST IMPLEMENT a mechanism based on local 4183 configuration which allows the MULTI_EXIT_DISC attribute to be 4184 removed from a route" 4186 Does anybody know how this can be done in IOS??? Looks like it 4187 cannot. 4189 Juniper??? 4191 Other code??? 4193 Change to "SHOULD"??? 4195 Enke responded that: 4197 As the MED value is treated as zero when the MED attribute is 4198 missing, removing the MED attribute is really equivalent to setting 4199 the value to zero. Based on this logic, one can argue that "MED 4200 removal" is supported by multiple vendors. 4202 However, I do see that the current text can be consolidated and 4203 cleaned up: 4205 ------------------------ 4206 5.1.4 MULTI_EXIT_DISC 4208 ... 4210 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4211 which allows the MULTI_EXIT_DISC attribute to be removed from a 4212 route. This MAY be done prior to determining the degree of 4213 preference of the route and performing route selection (decision 4214 process phases 1 and 2). 4216 An implementation MAY also (based on local configuration) alter the 4217 value of the MULTI_EXIT_DISC attribute received over an external 4218 link. If it does so, it shall do so prior to determining the degree 4219 of preference of the route and performing route selection (decision 4220 process phases 1 and 2). 4222 ------------------------- 4224 How about this: 4226 A BGP speaker MUST implement a mechanism based on local configuration 4227 which allows the value of MULTI_EXIT_DISC attribute of a received 4228 route to be altered. This shall be done prior to determining the 4229 degree of preference of the route and performing route selection 4230 (decision process phases 1 and 2). 4232 -------------------------- 4234 In responding to a question, Enke also added: 4236 > Humm. I thought with a missing MED it was preferable to be treated 4237 > as worst not as 0. 4239 It was changed a long time ago. Please see the following text in 4240 Sect. 9.1.2.2 of the draft: 4242 In the pseudo-code above, MED(n) is a function which returns the 4243 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4244 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4245 MULTI_EXIT_DISC value, i.e. 0. 4247 Curtis replied to Enke: 4249 If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a 4250 knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should 4251 change the spec to say that MED(n) returns the largest value possible 4252 is MULTI_EXIT_DISC is missing since this has better loop suppression 4253 behavior if the placement of MULTI_EXIT_DISC removal is moved in its 4254 position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out. In 4255 other words, no matter where the removal takes place, we are loop 4256 free without special rules about comparing EBGP before MED removal 4257 and then IBGP after MED removal. The only argument for MED(n) going 4258 to zero for missing MULTI_EXIT_DISC was that Cisco routers did that 4259 (and change would pose an operational issue if there wasn't a knob to 4260 facilitate the change). 4262 Note that when explicitly jamming a MULTI_EXIT_DISC value, such as 4263 zero, the issue of where in the decision process the MULTI_EXIT_DISC 4264 learned from the EBGP peers could still be used becomes a concern 4265 again. Unfortunately these implementation hints are necessary to 4266 remain loop free and so its hard to declare them out of scope, unless 4267 we forbid changing MULTI_EXIT_DISC and just allow it to be removed 4268 (which does not reflect current practice). 4270 Curtis also added: 4272 The other issue was MED handling. In "5.1.4 MULTI_EXIT_DISC": 4274 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4275 which allows the MULTI_EXIT_DISC attribute to be removed from a 4276 route. This MAY be done prior to determining the degree of 4277 preference of the route and performing route selection (decision 4278 process phases 1 and 2). 4280 An implementation MAY also (based on local configuration) alter the 4281 value of the MULTI_EXIT_DISC attribute received over an external 4282 link. If it does so, it shall do so prior to determining the degree 4283 of preference of the route and performing route selection (decision 4284 process phases 1 and 2). 4286 This doesn't sufficiently address the issue. 4288 The MED step in the decision process is (in 9.1.2.2): 4290 c) Remove from consideration routes with less-preferred 4291 MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable 4292 between routes learned from the same neighboring AS. Routes which do 4293 not have the MULTI_EXIT_DISC attribute are considered to have the 4294 lowest possible MULTI_EXIT_DISC value. 4296 This is also described in the following procedure: 4298 for m = all routes still under consideration 4299 for n = all routes still under consideration 4300 if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) 4301 remove route m from consideration 4303 In the pseudo-code above, MED(n) is a function which returns the 4304 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4305 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4306 MULTI_EXIT_DISC value, i.e. 0. 4308 Similarly, neighborAS(n) is a function which returns the neighbor AS 4309 from which the route was received. 4311 The problem is that a route loop can be formed. 4313 To avoid the route loop, two suggestions were made (2-3 years ago and 4314 nothing was done). One was to make MED(n) return infinity if there 4315 was no MULTI_EXIT_DISC. The other was to consider MULTI_EXIT_DISC in 4316 the decision process only for the purpose of selecting among the EBGP 4317 peers, then remove MULTI_EXIT_DISC, then use that best route in 4318 comparisons to IBGP learned routes. 4320 The statement in 5.1.4 "This MAY be done prior to determining the 4321 degree of preference of the route and performing route selection 4322 (decision process phases 1 and 2)" does not sufficiently address 4323 this. This implies that you MAY also remove after route selection, 4324 in which case field experience indicates you WILL get burned (unless 4325 you know about the caveat above). Initially this came up as an 4326 interoperability issue but later it was proven (in the field) that a 4327 Cisco and another Cisco could form a route loop until Cisco made this 4328 change. 4330 Additional wording is needed either in 5.1.4 or in 9.1.2.2. I 4331 suggest we put a forward reference in 5.1.4: 4333 [...]. This MAY be done prior to determining the degree of 4334 preference of the route and performing route selection (decision 4335 process phases 1 and 2). See section 9.1.2.2 for necessary restricts 4336 on this. 4338 Then in 9.1.2.2 add a clarification to the neighborAS(n) function and 4339 add to the existing text. 4341 Similarly, neighborAS(n) is a function which returns the neighbor AS 4342 from which the route was received. If the route is learned via IBGP, 4343 it is the neighbor AS from which the other IBGP speaker learned the 4344 route, not the internal AS. 4346 If a MULTI_EXIT_DISC attribute is removed before redistributing a 4347 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4348 in the comparison of EBGP learned routes, them removed, then the 4349 remaining EBGP learned route may be compared to the remaining IBGP 4350 learned routes, without considering the MULTI_EXIT_DISC attribute for 4351 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4352 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4353 learned route in the comparison with an IBGP learned route, then 4354 dropping the MULTI_EXIT_DISC and advertising the route has been 4355 proven to cause route loops. 4357 The loop is the classic I prefer your and you prefer mine problem. 4358 It occurs when the router is configured to remove MULTI_EXIT_DISC and 4359 advertise out a route so other routers can use IGP cost to select the 4360 best route. If two routers do this, as soon as they hear the route 4361 with no MULTI_EXIT_DISC from the other peer they start forwarding 4362 toward that peer but they continue to advertise to it since others 4363 IBGP peers are expected to select among the MULTI_EXIT_DISC free IBGP 4364 learned routes using the next step in the decision process, IGP cost. 4366 In this case, what you want is each router to prefer its own EBGP 4367 route, even though it has a MULTI_EXIT_DISC and the IBGP learned 4368 route from the same neighbor AS has had its MULTI_EXIT_DISC stripped 4369 off (or didn't have one, you can't tell which it is). You then want 4370 all of the IBGP peers with a MULTI_EXIT_DISC free route from that AS, 4371 or that have stripped the MULTI_EXIT_DISC to form one, to advertise 4372 them. Others in the AS will then use IGP cost to further resolve 4373 which exit point to use. It make a difference when the route is the 4374 aggregate route of another major provider. IGP cost yields what ISPs 4375 call "hot potatoe routing" and MED selects among multiple heavily 4376 loaded provider interconnects. 4378 [Aside: Having a missing MULTI_EXIT_DISC default to infinity would do 4379 exactly what the ISPs want it to do in the first place and be a lot 4380 easier to explain but we didn't fix that 2-3 years ago when the issue 4381 came up even though we had WG consensus that it was the right thing 4382 to do. The authors didn't act on it at the time (because Cisco 4383 didn't do it that way and the authors preferred to sit on the draft). 4384 At this point we might as well adequately document what we ended up 4385 with.... End of soap box. I don't take myself all that seriously so 4386 others shouldn't either. :-)] 4388 After some more discussion on this, we have this text: 4390 In 5.1.4 replace: 4392 An implementation MAY also (based on local configuration) alter the 4393 value of the MULTI_EXIT_DISC attribute received over EBGP. If it 4394 does so, it shall do so prior to determining the degree of preference 4395 of the route and performing route selection (decision process phases 4396 1 and 2). 4398 with: 4400 An implementation MAY also (based on local configuration) alter the 4401 value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY 4402 be done prior to determining the degree of preference of the route 4403 and performing route selection (decision process phases 1 and 2). 4404 See section 9.1.2.2 for necessary restricts on this. 4406 In 9.1.2.2 replace: 4408 Similarly, neighborAS(n) is a function which returns the neighbor AS 4409 from which the route was received. 4411 with: 4413 Similarly, neighborAS(n) is a function which returns the neighbor AS 4414 from which the route was received. If the route is learned via IBGP, 4415 and the other IBGP speaker didn't originate the route, it is the 4416 neighbor AS from which the other IBGP speaker learned the route. If 4417 the route is learned via IBGP, and the other IBGP speaker originated 4418 the route, it is the local AS. 4420 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 4421 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4422 in the comparison of EBGP learned routes, then removed, then the 4423 remaining EBGP learned route may be compared to the remaining IBGP 4424 learned routes, without considering the MULTI_EXIT_DISC attribute for 4425 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4426 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4427 learned route in the comparison with an IBGP learned route, then 4428 dropping the MULTI_EXIT_DISC and advertising the route has been 4429 proven to cause route loops. 4431 There have been no objections to this, so we are at consensus. 4433 2.64. MED for Originated Routes 4435 Status: Consensus 4436 Change: No 4437 Summary: The consensus is that there is not need to specify default 4438 values for MED in the base draft. 4440 Discussion: 4442 This issue began when it was pointed out that we do not specify the 4443 default values for MED in the base draft. 4445 There were a variety of responses, but the consensus is that since 4446 this is not relevant for interoperability, this does not need to be 4447 in the base spec. 4449 2.65. Rules for Aggregating with MED and NEXT_HOP 4451 Status: Consensus 4452 Change: Yes 4453 Summary: Clear up the text on aggregating with a MED. See the 4454 discussion for the text. 4456 Discussion: 4458 There is a proposal to relax this statement: 4460 "Routes that have the following attributes shall not be aggregated 4461 unless the corresponding attributes of each route are identical: 4462 MULTI_EXIT_DISC, NEXT_HOP." 4464 In his reply to the original mail, Curtis asserted that we should 4465 leave the MED rules alone, but perhaps we could relax the NEXT_HOP 4466 statement. 4468 This was revisited in the "aggregating with MED and NEXT_HOP" thread. 4470 Yakov suggested we replace: 4472 Routes that have the following attributes shall not be aggregated 4473 unless the corresponding attributes of each route are identical: 4474 MULTI_EXIT_DISC, NEXT_HOP. 4476 If the aggregation occurs as part of the update process, routes with 4477 different NEXT_HOP values can be aggregated when announced through an 4478 external BGP session. 4480 Path attributes that have different type codes can not be aggregated 4481 together. Path attributes of the same type code may be aggregated, 4482 according to the following rules: 4484 with: 4486 Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be 4487 aggregated. 4489 Path attributes that have different type codes can not be aggregated 4490 together. Path attributes of the same type code may be aggregated, 4491 according to the following rules: 4493 NEXT_HOP: When aggregating routes that have different NEXT_HOP 4494 attribute, the NEXT_HOP attribute of the aggregated route SHALL 4495 identify an interface on the router that performs the aggregation. 4497 This met with agreement. 4499 Dimitry asked if the "Routes that have different MULTI_EXIT_DESC 4500 attribute SHALL NOT be aggregated." sentence was unnecessary since it 4501 should be a matter of local policy. Jeff replied that it has been 4502 mentioned that removing this stipulation can cause routing loops. 4504 We are at consensus with this issue. 4506 2.66. Complex AS Path Aggregating 4508 Status: Consensus 4509 Change: No 4510 Summary: Since we have two implementations of this method, section 4511 6.8 stays in the specification. 4513 Discussion: 4515 Jonathan opened this discussion with: 4517 The part in the draft about complex AS path aggregation could/should 4518 be deleted. The current draft implies that when aggregating, for 4519 example (1st): 4521 1 2 4 3 4523 w/ 4525 3 4 6 5 4527 and 4529 5 6 7 8 4531 then 4533 1 2 {3 4 5 6} 7 8 4534 ...would be OK 4536 AFAIK, all implementations aggregate by either: (2nd)putting ONLY the 4537 local AS in the path (and setting the atomic) OR (3rd)by creating 1 4538 giant set and adding the local AS as a seq. 4540 So he proposed we remove this to reflect current code. 4542 Jeff replied that there is absolutely nothing wrong with doing 4543 complex aggregation, and there is no reason to remove this from the 4544 specification. 4546 Yakov responded that: 4548 Jonathan is certainly correct that the spec has to reflect current 4549 code. Therefore, unless there are at least two (interoperable) 4550 implementations that implement the algorithm described in "6.8 4551 Complex AS_PATH aggregation", this section has to be removed (this is 4552 irrespective of whether there is something wrong, or nothing wrong 4553 with complex aggregation). With this in mind, if you implement this 4554 algorithm please speak up within a week. If within a week we 4555 wouldn't know that there are at least two implementations the section 4556 will be removed. And likewise, if we hear that there are at least 4557 two implementations, the section will stay. 4559 Jeff replied: 4561 I am also fine with removing it. I just don't think its necessary, 4562 especially if One Of These Days someone decides that running policy 4563 based on as-adjacencies would be a Nice Thing and fixes their 4564 implementation to support "complex" aggregation of paths. 4566 That said, I am aware of no one who implements this. 4568 As an aside, in the thread "last thought on complex aggregation" Jeff 4569 supplied: 4571 I finally remembered what was bothering me about removing complex 4572 aggregation from the spec. 4574 If it is removed, people who do conformance tests and some 4575 implementations may take this to mean "it shall be illegal to have an 4576 AS_PATH that contains a SEQUENCE of a particular type after a SET". 4578 This would make a perfectly ok AS_PATH into one that isn't legal, 4579 even if no implementation currently generates it. 4581 Jonathan replied that he thought the issue was moot since no one has 4582 implemented this. 4584 John replied that, although he is a bit uncomfortable in removing 4585 this from the spec, he doesn't see any harm in doing so. 4587 With this in mind, Yakov suggested we consider the issue closed. 4589 So we will wait a week from 10/17 to see if anyone chimes in. 4591 Siva responded that they have implemented this functionality. So we 4592 need one more...Ben responded that they support this at Marconi as 4593 well. 4595 So we have two implementations, the section stays in the spec. We 4596 are at consensus with this issue. 4598 2.67. Counting AS_SET/AS_CONFED_* 4600 Status: Consensus 4601 Change: Yes 4602 Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to 4603 the BGP Confederations document. Update the base draft to reflect 4604 this by changing section 9.1.2.2. Specific text is at the end of the 4605 discussion. 4607 Discussion: 4609 Jonathan brought up some questions on how current implementations 4610 count AS_SET and AS_CONFED_* 4612 There were a variety of responses to this, answering his questions. 4613 Curtis pointed out that this behavior is covered in: 4615 That's in 9.1.2.2: 4617 a) Remove from consideration all routes which are not tied for having 4618 the smallest number of AS numbers present in their AS_PATH 4619 attributes. Note, that when counting this number, an AS_SET counts 4620 as 1, no matter how many ASs are in the set, and that, if the 4621 implementation supports [13], then AS numbers present in segments of 4622 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4623 count of AS numbers present in the AS_PATH. 4625 Jonathan replied that this might be at odds with what Juniper does, 4626 although he was unsure, and asked for clarification. 4628 This was discussed in the "New Issue AS path" thread. 4630 Yakov proposed that: 4632 The issue of route selection in the present of confederations belongs 4633 *not* to the base spec, but to the spec that describes BGP Confeds. 4634 With this in mind I would suggest to change in 9.1.2.2 from 4636 a) Remove from consideration all routes which are not tied for having 4637 the smallest number of AS numbers present in their AS_PATH 4638 attributes. Note, that when counting this number, an AS_SET counts 4639 as 1, no matter how many ASs are in the set, and that, if the 4640 implementation supports [13], then AS numbers present in segments of 4641 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4642 count of AS numbers present in the AS_PATH. 4644 to 4646 a) Remove from consideration all routes which are not tied for having 4647 the smallest number of AS numbers present in their AS_PATH 4648 attributes. Note, that when counting this number, an AS_SET counts 4649 as 1, no matter how many ASs are in the set. 4651 and ask the authors of BGP Confeds to update their document to cover 4652 how the presence of confeds impact route selection. 4654 This met with agreement, this issue is at consensus. 4656 2.68. Outbound Loop Detection 4658 Status: Consensus 4659 Change: No 4660 Summary: The consensus is, that while this may be a useful technique, 4661 it would break existing methods, and is otherwise out-of-scope for 4662 the base draft. It was suggested that this could be addressed in the 4663 update to RFC1772. 4665 Discussion: 4667 Jonathan brought up that: 4669 This paper (thanks Jeff) http://www.research.microsoft.com/scripts/ 4670 pubs/view.asp?TR_ID=MSR-TR-2000-08 indicates that it is better to do 4671 the loop detection outbound as well inbound. The current draft 4672 indicates that it only needs to be done inbound. IOS does it inbound 4673 as well as outbound. GateD/Juniper does it (did it ???) only 4674 inbound. 4676 So I propose we add: "An implementation MAY choose to not advertise 4677 routes to EBGP peers if these routes contain the AS of that peer in 4678 the AS path." after: "If the autonomous system number appears in the 4679 AS path the route may be stored in the Adj-RIB In, but unless the 4680 router is configured to accept routes with its own AS in the AS path, 4681 the route shall not be passed to the BGP Decision Process." 4683 *If there is at least one other implementation that does outbound 4684 pruning/loop-detection.* 4686 Yakov pointed out that this is ONLY applicable to the base draft if 4687 there are multiple implementations doing this. This issue will only 4688 be considered if these implementors come forward by 10/25/02. 4689 Otherwise the issue will be considered closed. 4691 Jeff replied that there was more at stake with this than if people 4692 had implemented it: 4694 My suggestion is that this can stay out of the base draft. While it 4695 is true that this speeds up convergence (per the paper), it doesn't 4696 affect interoperability. 4698 .in 4 Also, adding this specifically removes the ability from several 4699 implementations to be able to bridge a partitioned AS by permitting 4700 loops. (I'm not going to argue whether this is a Good way to do 4701 this, just that its done.) 4703 Its also worth noting that one could produce the same resultant 4704 speed-up by detecting the loop on an outbound basis and *not* 4705 applying the min*timers to the UPDATE. Thus, this would be a case of 4706 an advertisement of NLRI being treated the same, timer-wise, as the 4707 advertisement of WD_NLRI. 4709 I would suggest moving this suggestion for outbound loop detection in 4710 one form or another to the 1772 replacement. 4712 Yakov agreed with this. 4714 2.69. Appendix A - Other Documents 4716 Over the course of this discussion, a number of issues have been 4717 raised that the group though would be better dealt with in other 4718 documents. These additional documents, and their concomitant issues 4719 will be more fully addressed when the WG turns its focus to them. 4720 These projects are: 4722 1) Update RFC 1772: Application of the Border Gateway Protocol in the 4723 Internet. This will probably entail a complete rewrite. 4725 2) Update Route Reflector (2796) and Confederation (3065) RFC's 4726 regarding their impact on route selection. 4728 3) Write a new document covering BGP Multipath. .ne 4 4730 3. The Issues from -18 to -19 4732 This section lists the issues discussed on the list from November 4733 2002 to late February 2003. 4735 3.1. Reference to RFC 1772 4737 Status: Consensus 4738 Change: No 4739 Summary: Proposed changing RFC 1772 reference, since that document 4740 should be updated. 4742 Discussion: 4744 Jeff proposed that we reconsider referencing RFC 1772, since that 4745 document should be updated. 4747 Yakov pointed out that this is a non-normative reference and can just 4748 be left as is. 4750 Jeff agreed that this wasn't a big deal. We are at consensus to 4751 leave things as they are. 4753 This was discussed in the "-18 last call comments" thread. 4755 3.2. MUST/SHOULD Capitalization 4757 Status: Consensus 4758 Change: Yes 4759 Summary: Capitalize MUST/SHOULD where appropriate. 4761 Discussion: 4763 Jeff brought this up, and Yakov responded asking that he point out 4764 specific instances where this is needed. Jeff said he would do so, 4765 given some time. 4767 Yakov later replied that this would be fixed in the -19 version. 4769 Jeff replied with a master diff showing the MUST/SHOULDs, for the 4770 entire document please see the beginning of the thread entitled: 4771 "Issues list, #2: MUST/SHOULD Capitalization" 4772 This was discussed in the "18 last call comments" thread. This was 4773 also brought up in the "proxy: comments on draft -18" thread. 4775 3.3. Fix Update Error Subcode 7 -- accidently removed 4777 Status: Consensus 4778 Change: Yes 4779 Summary: Add error subcode 7 back in, it looks like it was 4780 inadvertently removed. Add deprecation text to Open Message Error 4781 subcode 5. 4783 Discussion: 4785 Jeff supplied: 4787 Update message error subcode 7 is removed. Especially in -18, it 4788 looks like an editing mistake based on where it would fall in the 4789 editing.. 4791 Yakov mentioned that this is addressed in Appendix A. 4793 Jeff replied: 4795 .in 4 What I would like to see is something like this: 4797 6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 - 4798 Invalid NEXT_HOP Attribute 4800 As it stands, 7 lies on a page boundary and looks like it got clipped 4801 by the roff. 4803 Yakov agreed, and also said he would add similar text for Open 4804 Message Error subcode 5. 4806 This was discussed in the "18 last call comments" thread. 4808 3.4. Section 5.1.4 - Editorial Comment 4810 Status: Consensus 4811 Change: Yes 4812 Summary: Fix "restricts" to "RESTRICTIONS" 4814 Discussion: 4816 Jeff proposed an editorial fix. This is agreed to. 4818 This was discussed in the "-18 last call comments" thread. 4820 3.5. Section 9.1 - Change "all peers" to "peers" 4822 Status: Consensus 4823 Change: Yes 4824 Summary: Section 9.1 - Change "all peers" to "peers" 4826 Discussion: 4828 Jeff proposed: 4830 .in 4 9.1: The output of the Decision Process is the set of routes 4831 that will be advertised to (delete all) peers; the selected routes 4832 will be stored in the local speaker's Adj-RIB-Out according to 4833 policy. 4835 The previous wording implied that routes in the LocRib MUST be placed 4836 in the adj-rib-out. 4838 Yakov agreed, this fix will be in the next revision. 4840 This was discussed in the "-18 last call comments" thread. 4842 3.6. AS Loop Detection & Implicit Withdraws 4844 Status: Consensus 4845 Change: Yes 4846 Summary: Update the text to reflect the AS Loop detection should be 4847 done in the BGP decision process. 4849 Discussion: 4851 John brought this up, and suggested: 4853 .in 4 I have one further comment just in case it's not perfectly 4854 obvious to everyone, which is that "ignore the UPDATE" is not 4855 strictly the action you take when receiving a looped update. Rather, 4856 you treat it as an implicit withdraw, i.e. you process it as any 4857 other update but treat the contained NLRI as unfeasible. 4859 I was going to write that this is sufficiently clear from the spec, 4860 but I regret to say that it isn't. Here is the fourth paragraph of 4861 section 9: 4863 .in 8 The information carried by the AS_PATH attribute is checked for 4864 AS loops. AS loop detection is done by scanning the full AS path (as 4865 specified in the AS_PATH attribute), and checking that the autonomous 4866 system number of the local system does not appear in the AS path. If 4867 the autonomous system number appears in the AS path the route may be 4868 stored in the Adj-RIB-In, but unless the router is configured to 4869 accept routes with its own autonomous system in the AS path, the 4870 route shall not be passed to the BGP Decision Process. Operations of 4871 a router that is configured to accept routes with its own autonomous 4872 system number in the AS path are outside the scope of this document. 4874 .in 4 I don't think this is quite right -- the decision process needs 4875 to be run if the looped routes had previously been advertised 4876 feasibly on the same session. This could be fixed by hacking the 4877 quoted paragraph, but it seems more straightforward to do it by 4878 removing the quoted paragraph and making the fix in 9.1.2 Phase 2 4879 instead. This could be done by inserting the following between the 4880 third and fourth paragraphs of 9.1.2 Phase 2: 4882 .in 8 If the AS_PATH attribute of a BGP route contains an AS loop, 4883 the BGP route should be excluded from the Phase 2 decision function. 4884 AS loop detection is done by scanning the full AS path (as specified 4885 in the AS_PATH attribute), and checking that the autonomous system 4886 number of the local system does not appear in the AS path. 4887 Operations of a router that is configured to accept routes with its 4888 own autonomous system number in the AS path are outside the scope of 4889 this document. 4891 .in 4 Section 9.3, first bullet, also addresses this topic, but I 4892 don't think it's sufficient. 4894 Yakov agreed that this was a change for the better and will include 4895 this in the next revision. 4897 We are at consensus on this issue. 4899 This is discussed in the "-18 last call comments" thread. 4901 3.7. Standardize FSM Timer Descriptions 4903 Status: Consensus 4904 Change: Yes 4905 Summary: Standardize the state descriptions on those listed in the 4906 discussion section of this issue. 4908 Discussion: 4910 Tom proposed: 4912 .in 4 I think a standard description would serve us better instead of 4913 using the following different ways (which I take all to refer to the 4914 same entity): 4916 delayBGP open timer BGP delay open timer BGP open delay timer delay 4917 open timer BGP delay timer 4919 .in 4 I suggest Open Delay timer (with those capitals) 4921 I believe that the corresponding flag is consistently referred to 4922 (apart from the capitalization) as Delay Open flag 4924 Yakov agreed with this suggestion, no one else disagreed, we are at 4925 consensus. 4927 This was discussed in the "BGP18-FSM-terminology" thread. 4929 3.8. FSM MIB enumerations 4931 Status: Consensus 4932 Change: Yes 4933 Summary: Move MIB references from the base spec into the MIB 4934 document. 4936 Discussion: 4938 Tom pointed out that: 4940 The FSM makes several references to putting values into MIB objects 4941 and while some of the values are defined, eg FSM error or Hold Timer 4942 expired, I can find no definition of the following in any of the BGP 4943 documents, MIB or otherwise. 4945 connect retry expired TCP disconnect administrative down collision 4946 detect closure Call Collision cease collision detected and dump 4947 connection Administrative stop 4949 I believe an implementation needs to be told these values somewhere 4950 and that there should be a reference to that place in bgp18. 4952 Jeff replied that to make things easier, the MIB references will be 4953 removed from the base spec, and into the MIB document. 4955 This was discussed in the "WG Last Call FSM MIB enumeration" thread, 4956 and the "bgp18 WG Last Call fsm MIB objects" thread. 4958 3.9. Make "delete routes" language consistent 4960 Status: Consensus 4961 Change: Yes 4962 Summary: Replace a variety of wording with "deletes all routes 4963 associated with this connection,". 4965 Discussion: 4967 Tom pointed out that we use a variety of language to say how we are 4968 going to delete routes in the FSM. He proposed that we instead use: 4970 - deletes all routes associated with this connection, 4972 This met with agreement, and will be reflected in the next version. 4974 This was discussed in the "bgp18 WG Last Call fsm delete action" 4975 thread. 4977 3.10. Correct OpenSent and OpenConfirm delete wording 4979 Status: Consensus 4980 Change: Yes 4981 Summary: Remove delete wording from OpenSent and OpenConfirm states. 4983 Discussion: 4985 Venu asked why there was delete wording in the OpenSent and 4986 OpenConfirm states when a BGP speaker cannot receive routes in these 4987 states. 4989 Jeff acknowledged that this was an error. Yakov agreed to fix the 4990 next version. 4992 This was discussed in the "bgp18 WG Last Call fsm delete action" 4993 thread. 4995 3.11. Incorrect next state when the delay open timer expires 4997 Status: Consensus 4998 Change: Yes 4999 Summary: Fix the next state. 5001 Discussion: 5003 Tom pointed out that: 5005 I believe that there is an incorrect next state when the delay open 5006 timer expires [event 12] in the Active state. The next state should 5007 be OpenSent and not OpenConfirm. 5009 OpenConfirm is for KeepAlive processing when Open messages have been 5010 sent and received. 5012 OpenSent is for Open sent and not yet received. 5014 The corresponding section in Connect state I believe is correct. 5016 Yakov agreed, and will fix this in the next revision. 5018 This was discussed in the "bgp18 WG Last Call fsm incorrect next 5019 state" 5021 3.12. Entering OpenConfirm / Adding "Stop OpenDelay" action 5023 Status: Consensus 5024 Change: Yes 5025 Summary: Add this text: 5027 Change 2 - Connect state event 17 (currently defined as going to 5028 Active) event 9 (stays in Connect state) 5030 new Text: 5032 In response to the connect retry timer expires event [Event 9], the 5033 local system: - drops the TCP connection, - restarts the connect 5034 retry timer, - stops the Open Delay timer and resets the timer to 5035 zero, - initiates a TCP connection to the other BGP peer, - continues 5036 to listen for a connection that may be initiated by the remote BGP 5037 peer, and - stays in Connect state. 5039 If the TCP connection fails [Event17], the local system: - restarts 5040 the connect retry timer, - stops the Open Delay timer and resets 5041 value to zero, - continues to listen for a connection that may be 5042 initiated by the remote BGP peer, and - changes its state to Active. 5044 Further discussion on Keepalives has been moved to issue 52. 5046 Discussion: 5048 This discussion began with Tom outlining these two points: 5050 When the OpenConfirm state is entered from OpenSent with the receipt 5051 of a valid open [Event 18], then a KeepAlive message is sent and the 5052 timer is started. 5054 When the OpenConfirm state is entered from Active or Connect on 5055 receipt of a valid open [Event 19], no message is sent, no timer is 5056 started. I believe this inconsistency is an error and should be 5057 corrected by adding these two actions in those two places. 5059 Sue replied: 5061 Just to clarify this comment: Event 19 = valid open with delay timer 5062 running 5064 Active = 1) awaiting TCP connection, or 2) TCP connection completed 5065 and awaiting the TCP connection with delay timer running 5067 Case 1: - should not see Event 19 In transition from Active to Open 5068 Confirm, the connection must have a TCP connection completed. Case 1 5069 does not have this occurring, so the transition must be avoided. 5071 Case 2: - should see Event 19 5073 - Open, Keepalive should be sent. 5075 Previous text: (Action H from FSM document) 5077 If an Open is received with the BGP Delay Open timer running, [Event 5078 19], the local system: - clears the connect retry timer [cleared to 5079 zero), - completes the BGP initialization, - stop and clears the BGP 5080 Open Delay timer, - Sends an Open Message, - sets the hold timer to a 5081 large value (4 minutes), and - changes its state to an Open Confirm. 5083 New text: [a New Action - N-2 : N + BGP keepalive sent] 5085 If an Open is received with the BGP Delay Open Timer running [Event 5086 19], the local system: - clear the connect retry timer [cleared to 5087 zero], - completes the BGP initialization, - stops and clears the BGP 5088 Open Delay timer, - Send an Open message, - Sends a Keepalive 5089 message, - If hold timer value is non-zero, - set keepalive timer - 5090 hold timer reset to negotiated value else if hold timer is zero, - 5091 reset the keepalive timer, and - reset the hold timer. 5093 - If the value of the autonomous system field is the same as the 5094 local Autonomous system number, set the connection status to a 5095 internal connection; otherwise it is "external". 5097 Tom and Sue discussed the OpenDelay state, and recalled that this was 5098 excluded a number of months ago as not reflecting current practice. 5100 By way of clarification, Sue added: 5102 1) Agree, this can occur in the Active state as well as the Connect 5103 state. Will you accept the earlier text below to be inserted both 5104 places? 5106 Background: 5108 The state machine for Event 19 is: 5110 Idle Connect Active Open Open Estb Sent Confirm 5111 ================================================ Event 19 | | | | | | 5112 | next state |Idle | Open | Open | Open |Idle | Idle | | | confirm| 5113 confirm| Confirm| | | 5114 ================================================ action | V | N-2 | 5115 N-2 | N | E-1 | E | ================================================ 5117 Per the State Machine. 5119 Action v - FSM Error Action E - FSM Error, drop connection - etc, 5120 drop routes Action E-1 - FSM Error, drop connection (lots of Action 5121 N-2 (text below) Action N (text below, without sending Open) 5123 2) Do you think that Event 19 is possible in the Open Sent state? 5125 Please answer this separately. 5127 Tom replied that: 5129 .in 4 1) yes I think the same text in both Active and Connect states 5130 is a good resolution 5132 2) complicated. As the fsm text stands, Event 19, along with a host 5133 of others, takes us back from Open Sent to Idle (I assume on the 5134 grounds this is an error condition) which seems very reasonable. 5136 But ...in quite a few places, such as Connect state events 2, 5137 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer 5138 when going to Idle or Active so we could then go from eg Idle with 5139 Manual start [event 1] to Connect to Open Sent all before the 5140 OpenDelay timer expires in which case event 19 can occur validly in 5141 Open Sent - obscure but possible. (This is also true with Active 5142 state and events 2, 17 and the default list at the end). 5144 But I think this is an error, and that when exiting Connect state or 5145 Active state as listed above, we should have an additional action to 5146 stop the OpenDelay timer in which case event 19 in Open Sent becomes 5147 an error condition (again). 5149 But but but as ever, I cannot speak with authority for 5150 implementations and so if implementations do not stop the OpenDelay 5151 timer when exiting as above, then Event 19 is valid in Open Sent 5152 state - obscure but possible (again). 5154 My wish is to add the extra action, stop OpenDelay timer, for the 5155 events listed above in Active and Connect states in the expectation 5156 that that is what people have or should have implemented. 5158 Tom added a response to Sue after some other threads have been 5159 discussed: .in 4 5161 You asked if event 19 (Open with OpenDelay timer running) was 5162 possible in OpenSent state; I gave a lengthy reply (below) to the 5163 effect yes it could because the OpenDelay timer did not always get 5164 stopped but the timer should be stopped in which case the event would 5165 not happen. 5167 Reading your responses to Siva , I see you include stopping the Open 5168 Delay timer in the action 'release all BGP resources' when going to 5169 Idle (which I missed seeing earlier in the year). 5171 That eliminates most but not all of the possibilities I mentioned. I 5172 now believe we would need to add the action 'stop OpenDelay timer' 5173 for Connect state event 17 (currently defined as going to Active) 5174 event 9 (stays in Connect state) 5176 in order to stop event 19 in Open Sent 5178 Sue replied that, she thought this was at consensus, and provided the 5179 new text, which is: 5181 Change 1: new text 5183 Active state - event 19 5185 If an Open is received with the Open Delay timer is running [Event 5186 19], the local system - clears the connect retry timer (cleared to 5187 zero), - stops and clears the Open Delay timer - completes the BGP 5188 initialization, - stops and clears the Open Delay timer - sends an 5189 OPEN message, - send a Keepalive message, - if the hold timer value 5190 is non-zero, - starts the keepalive timer to initial value, - resets 5191 the hold timer to the negotiated value, else if the hold timer is 5192 zero - resets the keepalive timer (set to zero), - resets the hold 5193 timer to zero. 5195 - changes its state to OpenConfirm. 5197 If the value of the autonomous system field is the same as the local 5198 Autonomous System number, set the connection status to an internal 5199 connection; otherwise it is "external". Change 2 - Connect state 5200 event 17 (currently defined as going to Active) event 9 (stays in 5201 Connect state) 5203 new Text: 5205 In response to the connect retry timer expires event [Event 9], the 5206 local system: - drops the TCP connection, - restarts the connect 5207 retry timer, - stops the Open Delay timer and resets the timer to 5208 zero, - initiates a TCP connection to the other BGP peer, - continues 5209 to listen for a connection that may be initiated by the remote BGP 5210 peer, and - stays in Connect state. If the TCP connection fails 5211 [Event17], the local system: - restarts the connect retry timer, - 5212 stops the Open Delay timer and resets value to zero, - continues to 5213 listen for a connection that may be initiated by the remote BGP peer, 5214 and - changes its state to Active. 5216 Tom replied that: 5218 .in 4 Change 2, stop Open Delay timer in Connect state events 9 and 5219 17, fine; that is what I understand to be the real issue 12. 5221 Change 1, event 19 in Active state, is IMHO issues 47 and 52. This 5222 is tangled because the initial paragraphs of Issue 12 in the issue 5223 list are nothing to to with stopping Open Delay timer and everything 5224 to to with sending a Keepalive message before entering Open Confirm 5225 state from Active or Connect state on event 19; which I raised and 5226 see as issue 52. Issue 47 was Siva's issue 28 and relates to a 5227 different action for Active state event 19. 5229 I agree with change 1 in that it adds in the sending of Keepalive 5230 which I believe essential; I think Siva needs to respond concerning 5231 issue 47. (nb the stop Open Delay action is duplicated) I wonder if 5232 we should use a different character for the bullet points under the 5233 if and else clauses to make it clear where they end ie - if the hold 5234 timer .... + do this + and this else if ... + do the other + and this 5236 But I still have an issue for Connect state event 19 where I believe, 5237 as for Active state event 19, we should send a Keepalive and start 5238 the Keepalive timer. I will pursue this as part of issue 52 if that 5239 suits you. I think the text will be the same as whatever we agree 5240 for Active state event 19. 5242 This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" 5243 thread. And also in the "Event 19 in Open Sent state was Re: bgp18 5244 WG Last Call fsm missing keepalive" thread. This also came up in the 5245 "issues 12 - consensus & two changes - 2nd message" thread. 5247 3.13. FSM Missing Next States 5249 Status: Consensus 5250 Change: Yes 5251 Summary: Seven sub-issues spawned to resolve each of the next-state 5252 questions. See each sub-issue for specifics. 5254 Discussion: 5256 This began with Tom pointing out 7 places where the next state was 5257 not clear. Interlaced with his comments below is the proposed text 5258 to fix the problems and the status of the issue. 5260 All sub-issues are at consensus. 5262 This conversation was started in the "bgp18 WG Last Call fsm missing 5263 next state" thread. 5265 3.13.1. FSM Missing Next States - Event 15 or 16 (Connect State) 5267 Status: Consensus 5268 Change: Yes 5269 Summary: Add next state of Connect. 5271 Discussion: 5273 Tom pointed out that: 5275 Connect State: 5277 If the TCP connection succeeds [Event 15 or Event 16], the local 5278 system checks the "Delay Open Flag". If the delay Open flag is set, 5279 the local system: **enters what state 5281 Sue proposed these changes: 5283 1) Connect State - Event 15 or Event 16 [consensus, editorial] 5285 note: The delay retry timer is utilized instead of the connect retry 5286 timer for the next two changes. Previous text: 5288 If the TCP connection succeeds [Event 15 or Event 16], local system 5289 checks the "Delay Open Flag". If the delay open flag is set, the 5290 local system: - clears the connect retry timer, - sets the BGP open 5291 delay timer to initial value If the Delay Open flag is not set, the 5292 local system: - clears the connect retry timer, - clear BGP Open 5293 Delay timer (set to zero), - completes the BGP initialization, - send 5294 an Open message to its peer, - sets hold timer to a large value, and 5295 - change the state to Open Sent. 5297 New text: 5299 If the TCP connection succeeds [Event 15 or Event 16], local system 5300 checks the Delay Open flag prior to processing: If the Delay Open 5301 flag is set, the local system: - clears the connect retry timer, - 5302 sets the BGP open delay timer to initial value, and - stays in the 5303 Connect state. 5305 If the Delay Open flag is not set, the local system: - clears the 5306 connect retry timer, - clears the BGP Delay timer (sets to zero), - 5307 completes the BGP initialization, - sends an Open message to its 5308 peer, - sets the hold timer to a large value, and - changes the state 5309 to Open Sent. 5311 Tom agreed that this was good, with the change to "Open Delay timer" 5312 as discussed in issue 7. 5314 This conversation was started in the "bgp18 WG Last Call fsm missing 5315 next state" thread. 5317 3.13.2. FSM Missing Next States - Event 14 (Connect State) 5319 Status: Consensus 5320 Change: Yes 5321 Summary: We selected option 2 from discussion as the correct text: 5323 2) treat it as an invalid response, reject the connection and see if 5324 a valid configured one comes within the connect timer's window. 5326 Discussion: 5328 Tom pointed out that: 5330 Connect State: 5332 If the TCP connection receives an indication that is invalid or 5333 unconfigured. [Event 14]: **enters what state 5335 Sue proposed these alternatives: 5337 2)Connect State - Event 14 [no consensus] 5339 Current Text: If the TCP connection receives an indication that that 5340 is invalid or unconfigured [Event 14], - the TCP connection is 5341 rejected. At the very least this section needs more "word smithing", 5342 so I'd like to change it for more clarity at least. 5344 I'm not sure this represents the implementations. What I'd like to 5345 do is query the implementations to see what they do if they receive a 5346 valid TCP connection with an invalid or unconfigured peer. Two 5347 options: Alternative 1: Count it as a valid response New Text: If a 5348 TCP connection is received that has an invalid format, or an 5349 unconfigured host [Event 14], the local system: - rejects the TCP 5350 connection, - increments the connect retry counter, - performs bgp 5351 peer oscillation checks. If bgp peer oscillation checks allow for a 5352 new connection, the bgp peer - restarts the Connect retry timer with 5353 configured value, and - enters the Active state. FSM table: Idle 5354 Connect Active Open-Sent Open-Confirm Establish Event-14 5355 ======================================================= Next state 5356 Idle | Active|Active|Open-Sent|Open-Confirm|Establish| 5357 ======================================================= action V | Y2 5358 | L | Ignore | Ignore | Ignore | 5359 ======================================================= Alternative 5360 2: Reject the connection and see if valid or configured one appears 5361 within the connect timer window. 5363 New Text: If a TCP connection is received that has an invalid format, 5364 or an unconfigured host [Event 14], the local system: - rejects the 5365 TCP connection, - and stays in the Connect state. 5367 FSM table: Idle Connect Active Open-Sent Open-Confirm Establish 5368 Event-14 ======================================================= Nxt 5369 state Idle |Connect|Active|Open-Sent|Open-Confirm|Establish| 5370 ======================================================= action V | L 5371 | L | Ignore | Ignore | Ignore | 5372 ======================================================= 5374 Sue then sent out a call to implementors to let the list know what 5375 they did with their FSMs. Tom replied that he agreed that we need to 5376 wait to see what the existing implementations do. He also suggested: 5378 **tp need a then clause here 'if bgp peer oscillation damping does 5379 not allow for a new connection, then the local system ???' 5381 be added before the FSM table in option 1 of the proposed text. 5383 Sue prodded the list saying that: 5385 Should the peer: 1) Treat it as a valid response, and enters the 5386 active state to watch for a another TCP connection with a valid peer. 5388 2) treat it as an invalid response, reject the connection and see if 5389 a valid configured one comes within the connect timer's window. 5391 Without further input, I will select option 2. 5393 Curtis replied that this was fine with him. 5395 There has been no further disagreement, we are at consensus on this. 5397 This conversation was started in the "bgp18 WG Last Call fsm missing 5398 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5399 input needed from developers" thread. 5401 3.13.3. FSM Missing Next States - Event 15 or 16 (Active State) 5403 Status: Consensus 5404 Change: Yes 5405 Summary: Add text listed in discussion. 5407 Discussion: 5409 Tom pointed out: 5411 Active State: 5413 A TCP connection succeeds [Event 15 or Event 16], the local system: 5414 process the TCP connection flags - If the BGP delay open flag is set: 5415 ** enters what state (I think this is an FSM error in TCP because it 5416 has not initiated a connection!) 5418 Sue proposed these changes: 5420 Previous text: A TCP connection succeeds [Event 15 or Event 16], the 5421 local system: process the TCP connection flags - If the BGP delay 5422 open flag is set: - clears the connect retry timer [through the 5423 following text: - and changes its state to Open Sent. 5425 New text: If the TCP connection succeeds [Event 15 or Event 16], 5426 local system checks the "Delay Open Flag" prior to processing: If the 5427 delay open flag is set, the local system: - clears the connect retry 5428 timer, - sets the BGP open delay timer to initial value, and - stays 5429 in the Active state. 5431 If the Delay Open flag is not set, the local system: - clears the 5432 connect retry timer, - clears the BGP Delay timer (sets to zero), - 5433 completes the BGP initialization, - sends an Open message to its 5434 peer, - sets the hold timer to a large value, and - changes the state 5435 to Open Sent. 5437 Tom agreed with this. 5439 This conversation was started in the "bgp18 WG Last Call fsm missing 5440 next state" thread. 5442 3.13.4. FSM Missing Next States - Event 13-17 (TCP Connection) 5444 Status: Consensus 5445 Change: Yes 5446 Summary: We selected: 5448 Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 be 5449 mandatory. 5451 Discussion: 5453 Tom started this by saying that: 5455 If the local system receives a valid TCP Indication [Event 13], the 5456 local system processes the TCP connection flags. ** enters what state 5458 If the local system receives a TCP indication that is invalid for 5459 this connection [Event 14]: ** enters what state 5461 Sue proposed we move this to the "fsm missing next state - Events 5462 13-17 and the TCP connection" thread. 5464 The response in this thread was: 5466 4) Active State, Event 13 [no consensus] 5) Active State, Event 14 5467 [no consensus] 5469 The problem with this state is it is difficult to exactly specify 5470 without discussing the TCP Messages that FSM document covers. I'll 5471 query if the implementors require all of events 13-17 as mandatory. 5473 Sue polled the implementors on the list with this query: 5475 These events are described in section 8.1.3. 5477 In our discussion in January through May of 2002, many implementers 5478 mapped their implementation onto the following TCP events list in 5479 8.1.3. 5481 Events 13 - 17 5483 Event 13 - TCP connection indication & valid remote peer 5485 Event 14 - TCP connection indication with invalid source or 5486 destination Event 15 - TCP connection request sent (by this peer) 5487 received an Acknowledgement 5489 [ local system sent a TCP SYN, Received a TCP SYN, ACK pair back, and 5490 Sent a TCP ACK] 5492 Event 16 - TCP connection confirmed 5494 [local system received a TCP SYN, sent a TCP SYN, ACK back, and 5495 received a TCP ACK] 5497 Event 17 - TCP connections 5499 Should we have all of these states? Which implementations support 5500 all of these Events? 5502 The full FSM text was snipped here for brevity. 5504 Sue prodded the list with: 5506 Do the implementors require Events 13 - 17 in the State machine ? 5508 Event 13 - TCP connection valid indication Event 14 - TCP connection 5509 invalid indication Event 15 - TCP connection request acknowledged 5510 Event 16 - TCP connection confirmed Event 17 - TCP connection fails 5512 Choice 1: Events 13 - 17 are mandatory Choice 2: Event 13 and Event 5513 14 be optional, and Events 15 - 17 be mandatory. If no one objects, 5514 we will use Choice 2. 5516 Curtis said this was fine with him. 5518 There has been no further disagreement, we are at consensus on this. 5519 This was started in the "bgp18 WG Last Call fsm missing next state" 5520 thread. And continued in the "fsm missing next state - Events 13-17 5521 and the TCP connection" thread. It was also discussed in the "BGP 5522 draft-19 - FSM input needed from developers" thread. 5524 3.13.5. FSM Missing Next States - Event 17 (Connect State) 5526 Status: Consensus 5527 Change: No 5528 Summary: Closed in favor of 13.4 5530 Discussion: 5532 If the local system receives a TCP connection failed [Event 17] 5533 (timeout or receives connection disconnect), the local system will: 5534 ** enters what state 5536 Sue replied with this: 5538 .in 4 comment: In the Active state, we may already have a connection 5539 and be awaiting the Open Delay timer. The TCP disconnect or timeout 5540 could occur in this state due to the "Open Delay Timer". If the TCP 5541 Disconnect is ignored, we could have some peer oscillation. 5543 If the we wait, then the connection retry timer needs to be kept 5544 running. The text below allows this timer. The real question is 5545 what is the status of the current implementations. 5547 I agree, the Active state and the connect state should match. 5549 Old Text: If the TCP connection fails (timeout or disconnection) 5550 [Event 17], the local system: - set TCP disconnect in the MIB reason 5551 code, - restart Connect retry timer (with initial value), - release 5552 all BGP resources, - Acknowledge the Drop of the TCP connection if 5553 TCP disconnect (FIN ACK), - Increment ConnectRetryCnt (connect retry 5554 count) by 1, and - performs the BGP peer oscillation damping process. 5556 Applicable FSM State table: FSM table old: Event 17 current: Idle 5557 Connect Active Open-Sent Open-Confirm Establish 5558 ========================================================= Next state 5559 Idle |Active |Idle |Active | Idle |Idle | | | | | | | 5560 ========================================================= action V | 5561 Y2 | G | Ignore| Track 2nd | Track 2nd | | | | | connection | 5562 connection| ========================================================= 5564 Alternative 1: 5566 FSM table new: 5568 Event 17 current: Idle Connect Active Open-Sent Open-Confirm 5569 Establish ========================================================= 5570 Next state Idle |Active |Active |Active | Idle |Idle | | | | | | | 5571 ========================================================= action V | 5572 G | G | Ignore| Track 2nd | Track 2nd | | | | | connection | 5573 connection| ========================================================= 5574 G: The local system: - restarts the connect retry timer (at initial 5575 value), - continues to listen for a connection that may be initiated 5576 by the remote peer, and - sets its next state to Active. 5578 New Text: (for Connect and Active state) If the TCP connection fails 5579 (timeout or disconnect) [Event 17], the local system: - restarts the 5580 connect retry timer, - continues to listen for a connection that may 5581 be initiated by the remote BGP peer, and - changes it state to 5582 Active. Alternative 2: FSM table new: Event 17 current: Idle Connect 5583 Active Open-Sent Open-Confirm Establish 5584 ========================================================= Next state 5585 Idle |Idle |Idle |Active | Idle |Idle | | | | | | | 5586 ========================================================= action V | 5587 Y2 | Y2 | Ignore| Track 2nd | Track 2nd | | | | | connection | 5588 connection| ========================================================= 5589 Next Text: If the location system receives a TCP connection failed 5590 [Event 17], the local system will: - increment the ConnectRetryCnt 5591 (connect retry count) by 1, - release all BGP resources associated 5592 with this connection, - perform BGP peer oscillation (if configured), 5593 and - go to Idle 5595 Y2 - is: The local system: 1) increments the ConnectRetryCnt (connect 5596 retry count) by 1, 2) releases all BGP resources associated with this 5597 connection, and 3) performs the BGP peer oscillation damping process 5599 if the damping process allows for a new connection, the local system: 5600 - restarts the connect retry timer (with initial value, and - goes to 5601 Idle If the damping process does not allow for a new connection, the 5602 local system - set the flags to damp the creation of a new bgp 5603 connection until a manual start occurs, and - goes to Idle. 5605 Tom agreed with the options, and stated that he preferred option 2. 5606 Sue is also happy with option 2, if no one else chimes in. 5608 After the issues list came out Tom responded to this issue, saying: 5610 .in 4 I think this issue SHOULD be administratively terminated. 5612 It relates to Connect state Event 17 (TCP connection fails) and I am 5613 credited with raising it; in fact, the issue I raised was missing 5614 next state for Active state event 17 and this has now been subsumed 5615 into 13.4 (but note that 13.4 does not explicitly say Active state - 5616 I know it should because I raised that issue too). I will ensure it 5617 does not get lost from any resolution of 13.4. 5619 And Connect state event 17 does appear as part of issue 45 which Siva 5620 raised so I think that either way, 13.5 can go. 5622 This conversation was started in the "bgp18 WG Last Call fsm missing 5623 next state" thread. 5625 3.13.6. FSM Missing Next States - Event 18 (Open Confirm) 5627 Status: Consensus 5628 Change: Yes 5629 Summary: This is the text: 5631 .in 4 In the Open Confirm state, a valid Open message [Event 22] is 5632 received. The BGP Peer connection is check to see if there is a 5633 collision per section 6.8. If this connection is to be dropped due 5634 to the call collision, the local system will drop the call by: 5636 - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to 5637 zero), - releases all BGP resources (this includes stopping the Open 5638 Delay Timer and reseting it to zero), - increments the 5639 ConnectRetryCnt by 1 (connect retry +count), and - optionally 5640 performs a BGP peer oscillation damping processing, and - enters the 5641 Idle State. 5643 Discussion: Tom opened this with: 5645 Open Confirm State: 5647 If the Open messages is valid [Event 18], the collision detect 5648 function is processed per section 6.8. If this connection is to be 5649 dropped due to call collision, the local system: ** enters what state 5651 Sue replied with: 5653 Here's my proposed text. Please let me know what you think. I think 5654 this is an editorial change. Old text: If the open message is valid, 5655 the collision detect function is processed per section 6.8. If this 5656 connection is to be dropped due to call collision, the local system: 5657 - sends a Notification with a Cease - resets the Connect timer (to 5658 zero), - releases all BGP resources, - Drop the TCP connection (sends 5659 a TCP FIN), - increments the ConnectRetryCnt by 1 (connect retry 5660 count), and - performs an BGP peer oscillation damping process. 5662 New text: If the open message is valid, the BGP peer connection is 5663 check to detect a collision per section 6.8. If this connection is 5664 to be dropped due to call collision, the local system: - sends a 5665 Notification with a Cease - resets the Connect timer (to zero), - 5666 releases all BGP resources, - Drop the TCP connection (sends a TCP 5667 FIN), - increments the ConnectRetryCnt by 1 (connect retry count), 5668 and - performs an BGP peer oscillation damping processing, and - 5669 enters the Idle State. notes: Collision detect impacts Open Sent, 5670 Open Confirm, and Established states. 5672 Tom replied: 5674 .in 4 I am still struggling with; we are in OpenConfirm so we already 5675 have received an Open from the remote peer and Event 18 is a second 5676 Open from the same peer. Perhaps my struggle is that I think in 5677 terms of two (or more) FSM for a given IP address pair so the Open 5678 Collision detection will occur when the/an- other FSM receives a 5679 valid Open in states Active/Connect/Open Sent and will generate Event 5680 22 into this FSM so Event 18 cannot occur. But yes, if Event 18 can 5681 occur in this FSM and this connection is to be dumped, then Idle 5682 state it should be as you suggest. I have slotted in [optionally] in 5683 front of the peer oscillation damping in your text because I think it 5684 should be optional:-) 5686 Sue replied: 5688 this mechanism allows a single fsm to handle both. 2 fsm and 1 fsm 5689 BGP FSM seem to exist. (I queried implementors a few times on this 5690 one. So, I just put in this change to provide the flexibility. 5692 Collision detect tends to give scrambled brains for most people.. As 5693 Dennis Ferguson said 2 years ago, that's the hardest part of the FSM. 5695 Sue then stated that she would query implementors to see what is 5696 being done. 5698 Sue prodded the list with: 5700 .in 4 In the Open Confirm state, a valid Open message [Event 22] is 5701 received. The BGP Peer connection is check to see if there is a 5702 collision per section 6.8. If this connection is to be dropped due 5703 to the call collision, the local system will drop the call by: 5705 - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to 5706 zero), - releases all BGP resources (this includes stopping the Open 5707 Delay Timer and reseting it to zero), - increments the 5708 ConnectRetryCnt by 1 (connect retry +count), and - optionally 5709 performs a BGP peer oscillation damping processing, and - enters the 5710 Idle State. 5712 Implementors need to verify if this text and the text for Event 22 5713 allows all implementors to perform the necessary Call Collision 5714 actions. If no objects, we will use this text. 5716 Curtis said he had no problem with this. 5718 There has been no disagreement, we are at consensus with this. 5720 This conversation was started in the "bgp18 WG Last Call fsm missing 5721 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5722 input needed from developers" thread. 5724 3.14. FSM - Peer Oscillation Damping 5726 Status: Consensus 5727 Change: Yes 5728 Summary: Change references to peer oscillation damping to consistent 5729 phrase: 5730 "[optionally] performs peer oscillation damping". Also remove old 5731 reference to "BGP Peer Restart Backoff Mechanisms". 5733 Discussion: 5735 Tom suggested we use consistent terminology to refer to peer 5736 oscillation damping. He also pointed out a stale reference. 5738 Yakov agreed to fix both of these. 5740 3.15. FSM - Consistent FSM Event Names 5742 Status: Consensus 5743 Change: Yes 5744 Summary: Make FSM names consistent. Specifics are in the discussion 5745 section. 5747 Discussion: 5749 Tom proposed that: 5751 .in 4 The event name used in the FSM show much variation to the point 5752 sometimes where I am not clear that it is always the same event (eg 5753 where the event name is qualified by a subset of the possible 5754 causes). Assuming that it is, I propose the following changes to 5755 make the wording consistent, clear and concise for event names. 5757 ** denotes changed text using the convention /'old text'/'new text'/ 5759 8. BGP Finite State machine 5761 Event1: Manual start Event2: Manual stop Event3: Automatic start 5762 **Event4: Manual start with passive TCP /establishment/flag/ 5763 **Event5: Automatic start with passive TCP /establishment/flag/ 5764 Event6: Automatic start with bgp_stop_flap option set **Event7: 5765 Auto//matic/ stop Event8: Idle hold timer expires Event9: Connect 5766 retry timer expires **Event10: Hold time//r/ expires Event11: 5767 Keepalive timer expires Event12: Open Delay timer expires **Event13: 5768 TCP connection valid indication **Event14: TCP connection invalid 5769 indication **Event15: TCP connection request /sent received an ACK/ 5770 acknowledged/ Event16: TCP connection confirmed Event17: TCP 5771 connection fails Event18: BGPOpen Event19: BGPOpen with *Open Delay 5772 timer running Event20: BGPHeaderErr Event21: BGPOpenMsgErr Event22: 5773 Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg 5774 Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr 5776 8.2.2 Finite State Machine 5778 Connect State: 5780 If the BGP port receives a ** valid TCP connection indication [Event 5781 13], 5783 If the TCP connection receives **an invalid indication [Event 14]: 5785 If the TCP connection fails **/(timeout or disconnect)// [Event17] 5787 Active State: 5789 If the local system receives a **valid TCP //indication/ [Event 13], 5790 If the local system receives a TCP connection failed [Event 17] 5791 **/(timeout or receives connection disconnect)//, 5793 Open Sent: If a connection in Open Sent is determined to be the 5794 connection that must be closed, an **/administrative collision 5795 detect/Open collision dump/ [Event 22] is signaled to the state 5796 machine. If such an **/administrative collision detect dump [Event 5797 22]/event/ is If a TCP **//connection valid/ indication [Event 13] or 5798 TCP **//connection/ request **//acknowledged/ [Event 15] Open Confirm 5799 State: ...or receives a TCP **/Disconnect// connection fails/ [Event 5800 17] from the 5802 In the event of **/TCP establishment//TCP connection valid indication 5803 /[Event 13] 5805 ...the local system will **/issue a call/generate an Open/ collision 5806 dump [Event 22]. When the local system receives a **/call/open/ 5807 collision dump event [Event 22]/such an event/, the 5809 Established State: **/disconnect from the underlying TCP/TCP 5810 connection fails/ [Event17], it: 5812 ... it will process **/a Call/an Open/ Collision dump event[Event 5813 22]. 5815 Notes: Event 4 title brought in line with text Event 5 title brought 5816 in line with text Event 7 title brought in line with text Event 13 5817 title shortened to be closer to text, text brought in line Event 14 5818 title shortened to be closer to text, text brought in line Event 15 5819 title brought in line with text Event 17 text brought in line with 5820 title (text often introduces qualifying conditions that are too 5821 restrictive) Event 22 text brought in line with title 5823 Sue replied: 5825 I will accept the text you proposed for the Event names. I will 5826 update the FSM text to include your changes. We'll consider issue 15 5827 in consensus. I've fixed the text. 5829 So we are at consensus here. 5831 This is discussed in the thread: "bgp18 WG Last Call fsm event 5832 names." It was also discussed in the "Issue 15 - Consistent FSM 5833 Event Names" thread. 5835 3.16. Many Editorial Comments 5837 Status: Consensus 5838 Change: Yes 5839 Summary: Many editorial suggestions, and what we are doing with them 5840 are listed below. Some issues have been broken out separately where 5841 there is a longer discussion on them. 5843 Discussion: 5845 Alex began this by presenting comments from an anonymous reviewer, 5846 unless otherwise noted, responses are from Yakov: 5848 > Almost all of these are simple clarifications. > > Section 1, page 5849 5: IGP definition - it's not clear from this > definition whether 5850 IBGP would be considered an IGP? any suggestion on how to improve the 5851 definition to clarify this issue would be appreciated. 5853 There was some further discussion on this and it was decided that 5854 people reading this document ought to know what an IGP is. 5856 > Section 3, page 7, para 4: Does RFC 1772 still represent the > 5857 *planned* use of BGP? Or the actual use? Or something > different 5858 from actual use? 5860 Perhaps we should just take out references to 1772. 5862 Further discussion seemed to indicate that this reference should 5863 stay. 5865 > Section 3, page 8, para 3 - "The hosts executing..." This > 5866 paragraph seems obsolete. 5868 I'll take it out. 5870 With regard to this, Siva asked if some route optimization vendors 5871 rely on this. Since this wasn't resolved, it is discussed further in 5872 issue 17. 5874 > Section 4.1, page 11 - Length is in network byte order. 5876 all the encodings are in network byte order. This applies not just 5877 to the BGP spec, but to other protocols as well. 5879 This comment was made about a number of fields. It was later agreed 5880 that a reference would be made to this at the beginning of the 5881 document. 5883 > Section 4.2, page 12 - Hold Time - what does a value of zero > 5884 indicate? 5886 if you read section 4.4 then you'll find that: If the negotiated Hold 5887 Time interval is zero, then periodic KEEPALIVE messages MUST NOT be 5888 sent. 5890 > Section 4.2, page 13 - BGP Identifier - network byte order? > "IP 5891 address" -> "IPv4 address" 5893 I'll put at the beginning a sentence saying that in the context of 5894 this document the term "IP address" means an IP Version 4 address. 5896 > Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> > 5897 "path attributes" 5899 fixed. 5901 > Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address" > 5902 Specify that this is 4 octets. > Reference here to multi-protocol 5903 extensions for IPv6 > nexthop? 5905 no. 5907 > RFC 2283 is unclear whether NEXT_HOP should always be > included 5908 when using multiprotocol extensions. Clarify > this here? 5910 It is already clarified in 2283bis. 5912 > Section 4.3, Page 17/18 - MED and LocalPref: > "non-negative" -> 5913 "unsigned" for consistency with > elsewhere. (non-negative might 5914 - Prefix: "IP address" -> "IPv4 address" > Prefix: "enough trailing 5915 bits to" -> "the minimum number > of trailing bits needed to" 5917 fixed. 5919 > Section 4.4, Page 20: - "BGP does not use any TCP-based keep-alive 5920 > mechanism to determine if peers are reachable". Is it worth noting 5921 > that TCP may still timeout the connection even if TCP keepalives 5922 are > turned off? 5924 the text is fine as it is. 5926 > Section 4.4, Page 20: > KEEPALIVE message consists" -> "A KEEPALIVE 5927 message consists" fixed. 5929 > Section 5, Page 23: "The same attribute can not appear more than > 5930 once with the Path Attributes field...". Does this mean the same > 5931 attribute type, or the same attribute type and value? 5933 the former (the same attribute type). 5935 > Section 5.1 "The usage of each BGP path attributes .." -> > 5936 attribute 5938 fixed. 5940 > Section 5.1.3 "IP address" -> "IPv4 address" > > "A BGP speaker 5941 must never advertise an address of a peer to that > peer as a 5942 NEXT_HOP, for a route that the speaker is originating." > suggest 5943 replace this text with: > "A route originated by a BGP speaker must 5944 never be advertised to a > peer using an address of that peer as 5945 NEXT_HOP" 5947 fixed. 5949 > Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which 5950 > allows the MULTI_EXIT_DISC to be removed from a route." Might > 5951 want to say that this is dangerous unless you received the route > 5952 from an EBGP peer? 5954 think we should keep the text as is. 5956 > Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE > 5957 message that is received from an external peer, then this > attribute 5958 MUST be ignored by the receiving speaker, except for the > case of 5959 BGP Confederations [RFC3065]." > - "ignored" might be taken to mean 5960 that you don't process it for > decision, but that you propagate it 5961 to internal peers. I might > write "silently removed" or something 5962 similar. 5964 I think the text is ok as is. 5966 > Section 5.1.5, para 2. "set of AS" -> "set of ASs" 5968 fixed. 5970 > Section 6.3: wrt NEXT_HOP semantic correctness: should we check > 5971 that a NEXT_HOP is not a multicast or broadcast address? 5973 I'll add to the definition of NEXT_HOP that it is a unicast address. 5975 > Section 6.3, page 32, para 7: "peer than sent" -> "peer that > 5976 sent" 5977 fixed. 5979 > Section 6.3: "if any attribute appears more than once" - does this 5980 > mean the same attribute type, or the same attribute type and > 5981 value? 5983 the former. 5985 > Section 6.8 "Comparing BGP identifiers is done by treating them as 5986 > (4-octet-long) unsigned integers". Need to convert to host byte > 5987 order before comparing. 5989 fixed. 5991 > Section 6.8, item 2: "closes BGP connection" -> "closes the BGP > 5992 connection"; "accepts BGP connection" -> "accepts the BGP 5993 connection". 5995 fixed. 5997 > Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it 5998 > is unclear for IBGP connections how to determine "the neighbor AS > 5999 from which the other IBGP speaker learned the route". If this is > 6000 really the leftmost entry in the AS path (or the local AS if the > 6001 path is empty), the spec should explicitly say so. 6003 fixed. 6005 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6006 > attribute is removed before..." The first sentence is pretty > 6007 nearly incomprehensible. 6009 This topic has some more discussion surrounding what text we should 6010 use to clarify this issue. This is followed up in issue 18. 6012 > Section 9.1.2.2 (d) > "d) If at least one of the candidate routes 6013 was received from > an external peer in a neighboring autonomous 6014 system, remove > from consideration all routes which were received 6015 from > internal peers." > For consistency with (c) and clarity, this 6016 might be reworded: > "d) If any of the candidate routes was learned 6017 via EBGP, > remove from consideration all routes which were learned 6018 by > IBGP." 6020 fixed. 6022 > Section 9.1.2.2 (e) > "cost (n) is better than cost (m)" > Given 6023 the definition of cost, it might be clearer to say > "cost (n) is 6024 lower than cost (m)" 6025 fixed. 6027 > Section 9.1.2.2 (g) > "neighbor address" has not been defined. 6029 I'll replace "neighbor address" with "peer address". 6031 > Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes 6032 > of all routes to be aggregated should be ignored." > > Perhaps 6033 "ignored" is ambiguous here, and it's not clear > whether should is a 6034 SHOULD. Suggest: > > "Any AGGREGATOR attributes from the routes to 6035 be aggregated > MUST NOT be included in the aggregated route." fixed. 6037 > Section 9.3 - shouldn't this subsection be moved to the discussion 6038 > of Phase 1 or Phase 2 of the decision process? Or at least move it 6039 > before Section 9.2. 6041 I think it is fine where it is now. 6043 > Appendix E, para 2: IP precedence has been deprecated. Delete > 6044 this paragraph, or replace with appropriate diffserv codepoint. 6046 deleted. 6048 > Security Considerations: > "BGP supports the ability to 6049 authenticate BGP messages by using > BGP authentication." > This 6050 sentence should be removed, and the Authentication > Information 6051 parameter has been deprecated. 6053 Please see the recent e-mail exchange on the Security Considerations 6055 See issue 19 for more on the Security Considerations section of the 6056 draft. 6058 These topics were discussed in the "proxy: more comments on the draft 6059 -18" thread. 6061 3.17. Section 3, Page 8, Paragraph 3 - Obsolete? 6063 Status: Consensus 6064 Change: Yes 6065 Summary: Leave the current definition of BGP Speaker, and normalize 6066 the text to use "BGP Speaker" instead of router. 6068 Discussion: 6070 This issue was spawned from the discussions in issue 16, 6071 specifically: 6073 Anonymous reviewer: 6075 > Section 3, page 8, para 3 - "The hosts executing..." This > 6076 paragraph seems obsolete. 6078 Yakov: 6080 I'll take it out. 6082 With regard to this, Siva asked if some route optimization vendors 6083 rely on this. 6085 Jeff replied: 6087 To provide context, this paragraph currently reads: 6089 : The hosts executing BGP need not be routers. A non-routing host : 6090 could exchange routing information with routers via EGP [RFC904] : or 6091 even an interior routing protocol. That non-routing host could : 6092 then use BGP to exchange routing information with a border router : 6093 in another Autonomous System. The implications and applications of : 6094 this architecture are for further study. .in 4 There are several 6095 deployed entities that could be considered to "exploit" this 6096 paragraph. Route collectors, route servers, bandwidth shapers and 6097 other optimizers. However, the original text may be showing its age 6098 a little bit. 6100 Perhaps the following might be a bit more appropriate: 6102 "The hosts executing BGP need not be routers. A non-routing host may 6103 exchange routing information with a BGP speaker for reasons that are 6104 outside the scope of this document." 6106 I would also propose adding to the same paragraph (but could be 6107 persuaded to drop it since it is *logically* redundant): "These non- 6108 routing hosts should exercise great care not to insert themselves 6109 into the forwarding path if they re-announce BGP routes." 6111 Yakov replied: 6113 Since operations of non-routing host are outside the scope of the 6114 document, and since the document doesn't preclude non-routing hosts 6115 to run BGP, I would prefer just to take the following paragraph out, 6116 and not to add any new text. 6118 The hosts executing BGP need not be routers. A non-routing host 6119 could exchange routing information with routers via EGP [RFC904] or 6120 even an interior routing protocol. That non-routing host could then 6121 use BGP to exchange routing information with a border router in 6122 another Autonomous System. The implications and applications of this 6123 architecture are for further study. 6125 Jeff replied that this was ok, and instead suggested: 6127 At the beginning of the document, we define: BGP speaker A router 6128 that implements BGP. 6130 This (potentially) restricts a speaker to being a router. 6131 Additionally, several spots in the text where we probably should say 6132 "BGP speaker", we use router. 6134 Yakov agreed to add this definition. 6136 Jeff replied that there still was a problem with this definition 6137 being too limiting. The discussion meandered off list for a couple 6138 of exchanges and these additional definitions were proposed: 6140 First Jeff proposed this: 6142 "A router that implements the BGP protocol. Non-routing hosts that 6143 also implement BGP are out of scope of this document." 6145 Then Andrew replied, that we should make sure the definition does not 6146 opt out entirely from making sure that non-routing hosts are 6147 interoperable: 6149 BGP Speaker .in 7 A router that implements the BGP protocol. The 6150 internal behavior of non-routing hosts that also implement BGP are 6151 out of scope of this document. However, in their interactions with 6152 routers, non-routing hosts must behave as if they were routers. 6154 And Jeff replied: 6156 BGP Speaker .in 7 A router that implements the BGP protocol. The 6157 internal behavior of non-routing hosts that also implement BGP are 6158 out of scope of this document. However, in their interactions with 6159 BGP speaking routers, non-routing hosts that implement BGP should be 6160 indistinguishable from a router on the wire. .in 4 6162 (or something like that - s/on the wire/ with whatever sounds best.) 6164 IOW, look like bgp on the wire - what you do internally is out of 6165 scope. 6167 Yakov replied, that we should keep the current definition, since it 6168 is clear that non-routing hosts are outside of the scope. Jeff 6169 responded that he is ok with that if we normalize the use of "BGP 6170 Speaker" instead of "BGP router" in the document. Yakov agreed to 6171 this, we are at consensus on this. 6173 This was discussed in the "proxy: more comments on draft -18" thread. 6174 And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - 6175 Obsolete?" thread. And also, the "issue 17 - final resolution" 6176 thread. 6178 3.18. MED Removal Text 6180 Status: Consensus 6181 Change: Yes 6182 Summary: Use text at the end of the discussion. 6184 Discussion: 6186 This issue is spawned from issue 16. 6188 An anonymous reviewer pointed out: 6190 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6191 > attribute is removed before..." The first sentence is pretty 6192 nearly > incomprehensible. 6194 Yakov replied: 6196 here is my attempt to clarify this: 6198 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6199 route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 6200 attribute may only be considered in the comparison of EBGP learned 6201 routes; the attribute is then removed, and then the remaining EBGP 6202 learned routes may be compared to the remaining IBGP learned routes, 6203 without considering the MULTI_EXIT_DISC attribute for those EBGP 6204 learned routes whose MULTI_EXIT_DISC attribute will be removed before 6205 advertising these routes to IBGP. 6207 Any further suggestions on how to improve this would be appreciated. 6209 Siva replied: 6211 How about this: 6213 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6214 route into IBGP, then comparison based on the MULT_EXIT_DISC 6215 attribute may (MUST?) be performed only among the EBGP learned 6216 routes. This comparison MUST be performed before the removal of the 6217 MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then be 6218 removed from those EBGP routes where such removal is required and 6219 which are still eligible. This is followed by comparison with IBGP 6220 learned routes. 6222 I think this reflects our objectives, which is: 6224 a) If MED is to be removed, compare EBGP routes based on the MED 6226 b) Then remove the MED 6228 c) Then do comparison with IBGP routes 6230 Andrew suggested: 6232 If a router is configured to remove a MULTI_EXIT_DISC attribute from 6233 a route learned from EBGP, before re-advertising it into IBGP the 6234 router MUST compare the route with other EBGP-learned routes before 6235 removing the MULTI_EXIT_DISC. Once this comparison is complete, the 6236 MED may be removed, and any remaining routes can be compared with 6237 IBGP routes to determine the best route. 6239 Yakov replied: 6241 Here is the text that will go in the next version of the draft: 6243 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6244 route into IBGP, then comparison based on the MULT_EXIT_DISC 6245 attribute MAY be performed only among the EBGP learned routes. This 6246 comparison MUST be performed before the removal of the 6247 MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then 6248 removed from those EBGP routes where such removal is required and 6249 which are still eligible. This is followed by comparison with IBGP 6250 learned routes. 6252 Matthew responded to this with: 6254 I think this new text is ambiguous. 6256 >Here is the text that will go in the next version of the draft: > > 6257 If a MULTI_EXIT_DISC attribute is removed before re-advertising a > 6258 route into IBGP, then comparison based on the MULT_EXIT_DISC > 6259 attribute MAY be performed only among the EBGP learned routes. 6261 .in 4 This could be taken to mean either that the comparison may be 6262 performed, and if it's performed it must be performed only between 6263 EBGP learned routes, or that the comparison must be performed, but it 6264 may be performed only between EBGP learned routes. 6266 > This comparison MUST be performed before the removal of the > 6267 MULTI_EXIT_DISC attribute. 6269 .in 4 If doing the comparison is optional, then I think that this 6270 sentence should read "If the comparison is performed, then it MUST be 6271 perfo..." 6273 > The MULT_EXIT_DISC attribute is then > removed from those EBGP 6274 routes where such removal is required and > which are still eligible. 6275 This is followed by comparison with > IBGP learned routes. 6277 6279 I think that it is desirable for an operator to be able to turn off 6280 MED processing entirely (including turning off all MED based 6281 comparisons), so I would suggest the following text: 6283 .in 5 If a MULTI_EXIT_DISC attribute is removed before re-advertising 6284 a route into IBGP, comparison based on the received MULTI_EXIT_DISC 6285 attribute MAY be performed. If an implementation chooses to perform 6286 this comparison, then the comparison MUST be performed only among 6287 EBGP learned routes, and it MUST be performed before the removal of 6288 the MULTI_EXIT_DISC attribute. 6290 Curtis replied to Yakov's message: 6292 .in 4 Looks good to me. 6294 I see no need to change "This comparison MUST be performed before the 6295 removal of the MULTI_EXIT_DISC attribute". There is no implication 6296 that MULTI_EXIT_DISC must be removed and the first sentence clearly 6297 indicates that doing so is not required therefore no ambiguity. 6298 Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second 6299 sentence would be redundant. 6301 After some further discussion we have reached full consensus with: 6303 .in 4 If a MULTI_EXIT_DISC attribute is removed before re-advertising 6304 a route into IBGP, then comparison based on the received EBGP 6305 MULTI_EXIT_DISC attribute MAY still be performed. If an 6306 implementation chooses to remove MULTI_EXIT_DISC, then the optional 6307 comparison on MULTI_EXIT_DISC if performed at all MUST be performed 6308 only among EBGP learned routes. The best EBGP learned route may then 6309 be compared with IBGP learned routes after the removal of the 6310 MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a 6311 subset of EBGP learned routes and the selected "best" EBGP learned 6312 route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC 6313 must be used in the comparison with IBGP learned routes. For IBGP 6314 learned routes the MULTI_EXIT_DISC MUST be used in route comparisons 6315 which reach this step in the decision process. 6317 This is discussed in the "proxy: more comments on draft 18" thread. 6318 And in the "issue 18" thread. 6320 3.19. Security Considerations 6322 Status: Consensus 6323 Change: Yes 6324 Summary: Fix Security Considerations section to include mandatory MD5 6325 auth and advance security considerations draft along with the base 6326 draft. 6328 Discussion: 6330 Yakov started this discussion by proposing text which would require 6331 TCP MD5 authentication for BGP implementations. This is to bring the 6332 spec in line with an IETF requirement that authentication be 6333 available. 6335 After some discussion the plan is to advance 6336 draft-ietf-idr-bgp-vuln-00.txt as Informational along with the base 6337 BGP specification. This draft will serve as the security analysis 6338 section of the base spec. 6340 This is discussed in the "revised Security Considerations section" 6341 thread. 6343 3.20. Peer Oscillation Damping 6345 Status: Consensus 6346 Change: No 6347 Summary: Keep the Peer Oscillation Damping reference in the 6348 specification. 6350 Discussion: 6352 This began when Siva proposed: 6354 .in 4 Since this feature is going to be added in a new draft, and its 6355 addition will change the operation of the state machine, can we 6356 remove all mention of it in the state machine ? As part of this 6357 removal, can we also remove the IdleHold Timer from the FSM since it 6358 is not useful in the absence of peer oscillation damping ? 6360 The draft that describes this procedure can then describe the change 6361 in the state machine required to do this. 6363 Sue replied that: 6365 The reason we should not remove the peer oscillation damping from the 6366 state machine: 6368 1) Deployed implementations support peer oscillation damping 2) Hooks 6369 for the additions in the FSM cannot be added later. 6371 These hooks are optional and do not need to be implemented. 6373 Siva replied: 6375 I understand. I am not trying to object to peer oscillation damping, 6376 I think it is a good idea and we have included it in our 6377 implementation as well. I was suggesting that instead of a partial 6378 description in this draft, it be completely described in the draft on 6379 peer oscillation damping. 6381 However, I do see your point, and unless there are any objections 6382 from others, I think we have consensus on this issue. 6384 This was discussed in the "Response to FSM input - Comments 1-10" 6385 thread: Comment #1. 6387 3.21. Session Attributes - IdleHold Timer 6389 Status: Consensus 6390 Change: Yes 6391 Summary: Add the text in the discussion section. 6393 Discussion: 6395 This discussion began with Siva asking: 6397 .in 4 Why have a Hold Timer and a Hold Time ? Can we replace this 6398 with just Hold timer ? 6400 Can we also add the following session attributes: 6402 a) DelayBgpOpenTimer b) IdleHold Timer (in case we choose not to 6403 remove this from the base FSM) 6405 Can we also add the following flag to the session attributes: a) 6406 DelayOpen Flag 6408 After some discussion we have this text on the table: 6410 Event8: Idle hold timer expires 6411 Definition: An Event generated when the Idle Hold Timer expires. The 6412 Idle Hold Timer is only used when the persistent peer oscillation 6413 damping function is enabled. 6415 % Implementations not implemented persistent % peer oscillations 6416 damping functions may not % have the Idle Hold Timer. Sue replied: 6418 I will accept the new text for the following total text: Event8: Idle 6419 hold timer expires 6421 Definition: An event generated when the Idle Hold Timer .in 24 6422 expires indicating that the session has completed a back-off period 6423 to prevent bgp peer oscillation. 6425 The Idle Hold Timer is only used when the persistent peer oscillation 6426 damping function is enabled. 6428 Implementations not implementing the persistent peer oscillation 6429 damping functions may not have the Idle Hold Timer. 6431 Status: Optional 6433 We are at consensus with this. 6435 Tom added a couple of minor edits, correcting the spelling of 6436 "persistent" in the third paragraph, and pointing out that: 6438 .in 4 oscillation damping functions may not have the Idle Hold ** 6439 function ** (because we only have function not functions in the 6440 previous sentence) Timer. 6442 Sue added the edits. 6444 Siva also liked the way this issue has turned out. 6446 This was discussed in the "Response to FSM input - Comments 1-10" 6447 thread: Comment #2. And in the "Draft 19 - issue #21" thread, 6448 alternately the "Draft 19 - Issue 21" thread. 6450 3.22. Specify New Attributes (Accept Connections/Peer Oscillation 6451 Damping) 6453 Status: Consensus 6454 Change: Yes 6455 Summary: Add the text in the discussion section to section 8.0. 6457 Discussion: 6459 This began with Siva proposing: 6461 Can we call these out as well: 6463 * Accept Connections from unconfigured peers (Enabled/Disabled) * 6464 Peer Oscillation Dampening (Enabled/Disabled) (In case we choose not 6465 to remove it from base spec) 6467 After some discussion we have this text on the table: 6469 The following will be added to 8.0 Optional parameters that may be 6470 supported either per connection or per implementation: 6472 1) Delay Open flag 2) Delay Open Timer 3) Perform automatic start 6473 flag 4) Passive TCP establishment flag 5) BGP stop_peer_flag flag 6) 6474 Idle Hold timer 7) Perform automatic stop flag 8) Perform Collision 6475 detect in Establish mode flag 6477 Sue accepted these changes. 6479 Tom added this correction for item 2 in Sue's text: 6481 2) Delay Open Timer 6483 ** Open Delay timer ** (for which we have consensus in Issue list v2 6484 item 7) 6486 Siva asked, and Sue accepted these additional changes: 6488 9) accept connections from un-configured peers 5) BGP stop_peer_flap 6489 flag 6491 We are at consensus on this. 6493 This was discussed in the "Response to FSM input - Comments 1-10" 6494 thread: Comment #3. This was also discussed in the "BGP Draft 19 - 6495 Close open items 22" thread. 6497 3.23. Event1/Event2 Clean Up 6499 Status: Consensus 6500 Change: Yes 6501 Summary: Use "Local system administrator" in both sections. 6503 Discussion: 6505 Siva proposed that we clean up the text for these Events by selecting 6506 either "Administrator" or "Local system" but not both. 6508 Sue proposed text using "Local system administrator" that was agreed 6509 on. 6511 This was discussed in the "Response to FSM input - Comments 1-10" 6512 thread: Comment #4. 6514 3.24. Events 3, 5, 6 & 7 Give Examples 6516 Status: Consensus 6517 Change: No 6518 Summary: Leave the examples out. 6520 Discussion: 6522 This began with Siva proposing we add examples for these event 6523 states. Sue believes this is largely out-of-scope, but did agree to 6524 move the example of "automatic stop" to the event description 6525 section. She asked for proposed text for additional examples. 6527 Sue replied that she has made the following changes, and asked if 6528 these worked for Siva. 6530 New text: Event7: Automatic stop 6532 Definition: Local system automatically stops the BGP connection. 6534 An example of an automatic stop event is exceeding the number of 6535 prefixes for a given peer and the local system automatically 6536 disconnecting the peer. 6538 Status: Optional depending on local system 6540 Siva thought this for Event 7 was fine. 6542 Sue replied to the list, saying that, previously examples had caused 6543 dissension, and asked if there was a strong feeling either way. 6545 Siva proposed this text for Events 3, 5 & 6: 6547 Event 3: Examples of this event are: When a connection is terminated 6548 during exchange of Open messages due to version failure 6550 Event 5: Examples of this event are: Similar to Event 3 6552 Event 6: Examples of this event are: Similar to Event 3 and b) When a 6553 Idle Hold timer expires (within local limit) 6555 Sue replied to this: 6557 I'm going to leave the examples out of events 3, 4, 6 since I've not 6558 heard any strong input on the mail list **and** I had strong comments 6559 on prior versions of the draft. I'd like to declare that issue 24 6560 has consensus. 6562 Siva agreed, we are at consensus on this issue. 6564 This was discussed in the "Response to FSM input - Comments 1-10" 6565 thread: Comment #5. This was also in the "Issue 25" thread, and the 6566 "Issue 25 - this is really issue 24" threads. This is also in the 6567 "Draft 19 - Issue 24" thread. 6569 3.25. Event 4 & 5 Session Initiation Text 6571 Status: Consensus 6572 Change: No 6573 Summary: Leave the text as is. 6575 Discussion: 6577 This began with Siva wanting to change: 6579 Definition: Local system automatically starts the BGP session with 6580 the passive flag enabled. The passive flag indicates that the peer 6581 will listen prior to establishing a connection. 6583 to: 6585 The passive flag indicates that the state machine will wait for 6586 specified peer to initiate a connection with the local system. If 6587 this does not happen within a specific time (hold time), the local 6588 system will then also attempt to initiate connection with the 6589 specified peer. 6591 Sue replied: 6593 The text in 8.2.1.1 indicates the definition of the passive flag. 6a) 6594 ========== My understanding of your text is that you want to replace 6595 in both sets of text: 6597 "The passive flag indicates the peer will listen prior to 6598 establishing a connection". 6600 with: 6602 "The passive flag indicates that the state machine will wait for the 6603 specified peer to initiate a connection with a local system. 6605 The problem with this sentence is that in the "unconfigured" case the 6606 phrase "specified" peer is confusing. I think the original text is 6607 clearer. 6609 6b) ========== If this does not happen within a specific time (hold 6610 time), the local system will then also attempt to initiate (a) 6611 connection with the specified peer. My comments: Again, the 6612 "specified peer" term is confusing. Also, the 2nd half of the 6613 statement mixes the actions of the state machine with the events. I 6614 believe this muddies the text instead of clarifying it. 6616 Siva and Sue later agreed to leave the text the same because of the 6617 Unconfigured + passive TCP connection + Delay Open situation. 6619 This was discussed in the "Response to FSM input - Comments 1-10" 6620 thread: Comment #6. 6622 3.26. Event 4 & 5 - bgp_stop_flap option 6624 Status: Consensus 6625 Change: Yes 6626 Summary: Add new event below. 6628 Discussion: 6630 This began with Siva asking: 6632 Won't a variant of this with bgp_stop_flap option set be required ? 6633 We can also achieve the same by using the bgp_stop-Flap option as a 6634 flag that is provided as an input to the state machine. 6636 Siva later clarified this to include: 6638 We already have Event 3 - Automatic Start Event 5 - Automatic start 6639 with bgp_stop_flap option set To make things consistent, shouldn't we 6640 either a) Add 3 new events : .in 24 1) Manual start with bgp_stop 6641 flap option set 2) Manual start with passive TCP establishment and 6642 bgp_stop_flap option set 3) Automatic start with passive TCP 6643 establishment and bgp_stop_flap option set 6645 or b) Remove Event 6, and rely on a flag to tell us wither peer flap 6646 damping is to be performed for the session or not. 6648 Sue said she preferred option A. And stated that #1 & #2 are 6649 infeasible, but that we need to add #3. 6651 Tom replied: 6653 .in 4 But if we add an event, then we must add and agree on actions 6654 for all six existing states so I think to say that adding a new event 6655 settle things might be naive. 6657 If we do add 3) Automatic start with passive TCP establishment and 6658 bgp_stop_flap option set 6660 which I understand is Sue's resolution, then for Idle state the 6661 actions are straightforward but for the other five, is the event 6662 completely ignored? If so, does it mean that the passive flag and 6663 the bgp_stop_flap option are ignored and we carry on as if we were 6664 when we were started which may have been without them. Or is the 6665 fact of starting ignored but the flags remain set and so color the 6666 effect of other events? Needs defining. 6668 Jeff replied to this, quoting the existing draft: 6670 The start events [Event 1, 3-6] are ignored in connect state. 6672 The start events [Event1, 3-6] are ignored in the Active state. 6674 The Start events [Event1, 3-6] are ignored in the OpenSent state. 6676 Any start event [Event1, 3-6] is ignored in the OpenConfirm state. 6678 Any start event (Event 1, 3-6) is ignored in the Established state. 6680 And elaborated, saying that: 6682 .in 4 "ignore" means do nothing. This means don't twiddle with the 6683 flags. :-) 6685 The text that was finally agreed on is: 6687 Event 7: Automatic start with bgp_stop flap option set and passive 6688 TCP establishment option set Definition: Local system automatically 6689 starts the .in 24 BGP peer connection with peer oscillation damping 6690 enabled and passive TCP establishment enabled. The exact method of 6691 damping persistent peer oscillations is left up to the 6692 implementation, and is outside the scope of this document. 6694 Status: Optional, used only if the bgp peer has .in 24 enabled bgp 6695 peer oscillation damping with following optional flags settings 6696 below. 6698 Optional attributes: 1) Perform automatic start flag SHOULD be set 2) 6699 BGP stop_peer_flap flag SHOULD be set I've re-ordered the Timer 6700 events to keep the text changes down to a minimum. 6702 action 9 - connect retry timer action 10 - Hold Timer expires action 6703 11 - Keepalive timer expires action 13 - Open Delay timer expires 6704 action 14 - Idle Hold timer expires 6706 All other events are incremented by 1 6708 This was discussed in the "Response to FSM input - Comments 1-10" 6709 thread: Comment #7. 6711 3.27. Event 5 Clarification 6713 Status: Consensus 6714 Change: No 6715 Summary: Leave the text as is. 6717 Discussion: 6719 This began when Siva asked that in event 5: 6721 .in 4 Is it correct that this event will occur only when we want to 6722 restart a connection (after it had been terminated due to some reason 6723 beside administrative action) that we had accepted from an 6724 unconfigured peer ? 6726 Sue replied: 6728 .in 4 The automatic start function is an implementation specific 6729 mechanism. This text does not seek to restrict it in any fashion. 6731 Siva said that although he felt his original clarification would be 6732 more useful to new implementors he is ok with the text as is. 6734 This was discussed in the "Response to FSM input - Comments 1-10" 6735 thread: Comment #8. 6737 3.28. Timer Events Definition - Make Consistent 6739 Status: Consensus 6740 Change: Yes 6741 Summary: Change text to use "generate" across the board. 6743 Discussion: 6745 Can we use similar language for Events 8-12 to make them consistent? 6747 It was agreed that we will use "generate" i.e.: 6749 Event 8: An event generated when the Idle Hold timer expires. Event 6750 9: An event generated when the ConnectRetry timer expires. Event 10: 6751 An event generated when the Hold timer expires. Event 11: An event 6752 generated when the Keepalive timer expires Event 12: An event 6753 generated when the Delay BGP Open timer expires. This is at 6754 consensus. 6756 This was discussed in the "Response to FSM input - Comments 1-10" 6757 thread Comment #9. 6759 3.29. Event 8 - Clean Up 6761 Status: Consensus 6762 Change: Yes 6763 Summary: Clean up first sentence. New text below. 6765 Discussion: 6767 Siva began this by asking if we could clean up the wording of Event 6768 8. 6770 After some discussion with Sue we are at this change for the first 6771 sentence: 6773 An event triggered by the expiry of the Idle Hold timer, indicating 6774 that the session has completed waiting for a back-off period to 6775 prevent bgp peer oscillation. 6777 This was discussed in the "Response to FSM input - Comments 1-10" 6778 thread: Comment #10. 6780 3.30. Hold Timer - Split? 6782 Status: Consensus 6783 Change: No 6784 Summary: Keep the hold timer text as is. 6786 Discussion: 6788 Siva proposed that since: 6790 .in 4 We use the hold timer for two purposes 6792 * Waiting for an open message (with a default value of 240 seconds) * 6793 Waiting for Keepalives (with a default value of 90 seconds) 6795 Can we use two different timers (or at least call them two different 6796 timer events) ? 6797 Sue replied that this is not how it is implemented currently. Siva 6798 replied that we have two conceptually different timers, but that it 6799 would certainly work to only have one, since only one needs to be 6800 running at any given time. 6802 Tom agreed that we can keep things as is. 6804 This was discussed in the "Comments 11-20" thread: Comment #11. 6806 3.31. OpenDelay Timer Definition 6808 Status: Consensus 6809 Change: Yes - See issue 28 6810 Summary: This is fixed by the fixing of issue 28. 6812 Discussion: 6814 This began with Siva's request that we add something to Event 12 to 6815 specify what to do when the timer expires. This seems to have been 6816 addressed in issue 28. 6818 This was discussed in the "Comments 11-20" thread: Comment #12. 6820 3.32. Definition of TCP Connection Accept (Event 13) 6822 Status: Consensus 6823 Change: Yes 6824 Summary: Change "Definition" text as indicated below. 6826 Discussion: 6828 Siva proposed that we change text from referring to "TCP connection 6829 request" to "receiving a TCP connection". This led to this proposed 6830 text: 6832 Definition: Event indicating the reception of a TCP connection 6833 request with a valid source IP address and TCP port, and valid 6834 destination IP address and TCP Port. The definition of invalid 6835 source address and port and invalid destination address is left to 6836 the implementation. 6838 This met with agreement. 6840 This thread also discussed the idea of filtering the incoming 6841 address/port. It was decided that this was implementation dependent. 6843 This was discussed in the "Comments 11-20" thread: Comment #13. 6845 3.33. Event 13 & 14 - Valid Addresses & Ports 6847 Status: Consensus 6848 Change: Yes 6849 Summary: See text at the end of the discussion. 6851 Discussion: 6853 With regard to Event 13 & 14, Siva raised questions about: 1) What 6854 does it mean to validate a port, and 2) Should we state what we 6855 consider an invalid IP address to be? 6857 Sue replied that this is local policy and is implementation 6858 dependent. Siva agreed regarding the source port & IP address, but 6859 disagreed about the destination port. He argued that we need to know 6860 the destination port for interoperability. 6862 Sue asked Siva to provide some text. 6864 After a long lull, Sue replied with: 6866 I would like to keep the current text of "Should" in the following 6867 text "BGP's destination port SHOULD be port 179 as defined by IANA." 6869 Should indicates that it normally should be 179. If an 6870 implementation allows for an alternative TCP port, it is still valid 6871 as the "MUST" is not indicated. 6873 There have been no further comments on this, the chairs have decided 6874 to close it. 6876 This was discussed in the "Comments 11-20" thread: Comment #14. This 6877 was also in the "BGP-19: Issue 33" thread. 6879 3.34. Event 17 - TCP Connection Fails to TCP Connection Termination 6881 Status: Consensus 6882 Change: Yes 6883 Summary: Change the text to "fails." 6885 Discussion: 6887 This began with Siva observing: 6889 .in 4 This event can occur even when the transport connection is 6890 closed by the other end. Since this does not reflect a 'failure ', 6891 can we change the event name to 6892 % Event17: TCP connection termination 6894 Sue replied that: 6896 Discussion: It both terminates from the remote site and can "timeout" 6897 - fail. Suggestions? I can use "disconnect", what do you think. 6899 Siva replied that this was a minor issue, and on further reflection, 6900 either "fails" or "disconnect" would be acceptable. 6902 Sue replied that she has accepted Siva's comments, and the text will 6903 be changed to "fails". 6905 This was discussed in the "Comments 11-20" thread: Comment #15. This 6906 was also discussed in the "BGP-19: Issue 34-35, 40-48" thread. 6908 3.35. Making Definition Style Consistent 6910 Status: Consensus 6911 Change: Yes 6912 Summary: Adopt consistent style for the definition of events. 6914 Discussion: 6916 This started with Siva asking if we could make the definition style 6917 consistent across events. Sue replied to this with text for 13-17, 6918 Siva clarified that he was talking more about 18-21, and proposed 6919 text. 6921 We are agreed on the text for 13-17: 6923 Event13: TCP connection indication and valid remote peer 6925 Definition: Event indicating the local system reception .in 24 of a 6926 TCP connection request with a valid source IP address and TCP port, 6927 and valid destination IP address and TCP Port. The definition of 6928 invalid source, and invalid destination IP address is left to the 6929 implementation. 6931 BGP's destination port SHOULD be port 179 as defined by IANA. 6933 TCP connection request is denoted by the local system receiving a TCP 6934 SYN. 6936 Status: Mandatory (Optional) 6938 Event14: RCV TCP connection indication with invalid source or 6939 destination Definition: Event indicating the local system reception 6940 of a TCP connection request with either an invalid source address or 6941 port number or an invalid destination address or port number. BGP 6942 destination port number SHOULD be 179 as defined by IANA. 6944 Again, a TCP connection request denoted by local system receiving a 6945 TCP SYN. Status: Mandatory (Optional) Event15: TCP connection 6946 request sent received an ACK. 6948 Definition: Event indicating the Local system's request to establish 6949 a TCP connection to the remote peer. The local system's TCP session 6950 sent a TCP SYN, and received a TCP SYN, ACK pair of messages, and 6951 Sent a TCP ACK. Status: Mandatory Event16: TCP connection confirmed 6952 Definition: Event indicates that the local system receiving a 6953 confirmation that the TCP connection has been established by the 6954 remote site. 6956 The remote peer's TCP engine sent a TCP SYN. The local peer's TCP 6957 engine sent a SYN, ACK pair, and now has received a final ACK. 6958 Status: Mandatory Event17: TCP connection fails Definition: Event 6959 indicates that the local system has received a TCP connection failure 6960 notice. 6962 The remote BGP peer's TCP machine could have sent a FIN. The local 6963 peer would respond with a FIN-ACK. Another alternative is that the 6964 local peer indicated a timeout in the TCP session and downed the 6965 connection. Status: Mandatory 6967 Siva proposed these changes for 18-21: 6969 Event18: BGPOpen Definition: An event indicating that a valid Open 6970 message has been received. 6972 with Event18: BGPOpen Definition: An event is generated when a valid 6973 Open message has been received. 6975 Event19: BGPOpen with BGP Delay Open Timer running Definition: An 6976 event indicating that a valid Open message has been successful 6977 established for a peer that is currently delaying the sending of an 6978 BGP Open message. 6980 with 6982 Event19: BGPOpen with BGP Open Delay Timer running Definition: An 6983 event is generated when a valid Open message has been received for a 6984 peer that is currently delaying the sending of a BGP Open message. 6986 Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer" 6987 per issue 7. Event20: BGPHeaderErr Definition: BGP message header is 6988 not valid. 6990 with 6992 Event20: BGPHeaderErr Definition: An event is generated when a 6993 received BGP message header is not valid. 6995 Event21: BGPOpenMsgErr Definition: An BGP Open message has been 6996 received with errors. 6998 with Event21: BGPOpenMsgErr Definition: An event is generated when 6999 BGP Open message with errors has been received. 7001 Sue replied that she accepted Siva's comments, so we are at consensus 7002 here. 7004 This was discussed in the "Comments 11-20" thread: Comment #16. This 7005 also came up in the "BGP-19: Issue 34-35, 40-48" thread. 7007 3.36. Event 19 - Definition Cleanup 7009 Status: Consensus 7010 Change: Yes 7011 Summary: Replace definition for Event 19 with the text in the 7012 discussion. 7014 Discussion: 7016 Siva proposed we replace: 7018 .in 4 Definition: An event indicating that a valid Open Message has 7019 been successful established for a peer that is currently delaying the 7020 sending of an BGP Open message. 7022 with: 7024 .in 4 Definition: An event indicating that a valid OPEN Message has 7025 been received for a peer that has a successfully established 7026 transport connection and is currently delaying the sending of a BGP 7027 open message 7029 in Event 19. Sue agreed to the changes. 7031 This was discussed in the "Comments 11-20" thread: Comment #17. 7033 3.37. Event 22 - Cleanup 7035 Status: Consensus 7036 Change: Yes 7037 Summary: Replace Event 22 definition with the text from the 7038 discussion. 7040 Discussion: 7042 Siva began with observing: 7044 Event22: Open collision discard Definition: An event generated 7045 administratively when a connection Collision has been detected while 7046 processing an incoming Open message. This connection has been 7048 Isn't this event 'automatically' generated, since it is a system 7049 generated event ? 7051 Sue replied that: 7053 response: How this generated is implementation specific. The 7054 "administratively" is to cover policy. 7056 Siva also proposed an editorial fix with: 7058 Event 22 is an administrative could occur if FSM is implemented as 7059 two 7061 The word event is missing. How about 7063 Event 22 is an automatic event that could occur if FSM is implemented 7064 as two 7066 Sue replied with this rewritten text: 7068 Event22: Open collision dump Definition: An event generated 7069 administratively when a connection collision has been detected while 7070 processing an incoming OPEN message and this connection has been 7071 selected to disconnected. See Section 6.8 for more information on 7072 collision detection. 7074 Event22 is an administrative based only implementation specific 7075 policy. This Event may occur if the FSM is implemented as two linked 7076 state machines. 7078 Siva agreed with this new text. 7080 This was discussed in the "Comments 11-20" thread: Comment #18. 7082 3.38. FSM Description - ConnectRetry Count 7084 Status: Consensus 7085 Change: No 7086 Summary: Leave the counter text alone, since it is used in peer 7087 oscillation and will be in the MIB. 7089 Discussion: 7091 Siva opened with this question: 7093 The Connect Retry count is updated by the FSM but never used. In the 7094 absence of peer oscillation damping, will this be used to stop 7095 connection establishment attempts after a certain maximum number ? 7097 Yes, this is either implementation specific or is it based on 7098 the peer oscillation damping draft. 7100 Can we include the use of this counter in some place ? 7102 Connect retry counter 1) Will be utilized by the peer 7103 oscillation damping draft. 2) Will be included in bgp-4-mibv2-xx. I 7104 just check and I didn't find it. 7106 Do you still want text in the main? 7108 To which Siva replied that he believes we can leave the main text 7109 alone. 7111 This was discussed in the "Comments 11-20" thread: Comment #19. 7113 3.39. Handling Event 7 (Auto Stop) to Idle State processing 7115 Status: Consensus 7116 Change: Yes 7117 Summary: Fix the text as indicated in the discussion. 7119 Discussion: 7121 Siva began with: 7123 .in 4 The handling of Event 7 is missing from the Idle State 7124 processing. Can we add this ? How about replacing 7126 An manual stop event (Event2) is ignored in the Idle state. 7128 with 7129 Manual stop (Event 2) and Auto stop (Event 7) events are ignored in 7130 the Idle state 7132 Sue replied that she would add the text. 7134 This was discussed in the "Comments 11-20" thread: Comment #20. 7136 3.40. Clearing the Connection Retry Timer 7138 Status: Consensus 7139 Change: No 7140 Summary: Leave things alone, since it is better to be redundant than 7141 to let something slip through. 7143 Discussion: 7145 Siva opened with the observation: 7147 .in 4 There are a few sections where the FSM draft states that the 7148 Connection Retry timer needs to be reset, whereas the connect retry 7149 timer had been cleared prior to entering that state. We can remove 7150 these instructions to clear the connect retry timer. 7152 List of places where the connect retry timer need not be cleared 7154 a) Handling of Event 19 in the Connect State b) Handling of Events 12 7155 in the Active State c) All cases where it is referred to in the 7156 OpenSent, OpenConfirm and Established states 7158 Sue replied: 7160 Comment: 1) Does it hurt to have the connect retry timer cleared at 7161 these points, since it has already been cleared. 7163 I felt it eased the implementations to allow the action routines to 7164 be shared across as many states as possible. You can see this a bit 7165 more actively. 7167 Tom replied to this: 7169 .in 4 I propose we leave it in and close this issue. 7171 1) To take out an action as redundant you need to be supremely 7172 confident that it really cannot make a difference. I am not 7173 (supremely confident); rather, the more I look at the FSM, the more 7174 places I find where actions are missing, as I have posted to the 7175 list, from obscure yet possible sequences of events and timing. And 7176 there is an outstanding issue of mine which flagged seven places 7177 where the next state was missing and so I think it impossible for any 7178 one to be confident that any particular action is redundant until 7179 that is cleared up and that is proving complex in some cases. So, 7180 play safe, keep them in. 7182 2) The argument for removing them is that the number of possible 7183 distinct action lists is increased. True - it will mean that an 7184 implementor will have to code more code when first implementing BGP. 7186 For me this is no contest; keeping it safe at the possible cost of 7187 redundancy outweighs the one-off cost of additional implementation. 7189 So keep the actions in and close the issue. 7191 Jeff replied that he agreed with Tom on this. 7193 Siva concurred, that this approach was acceptable. 7195 Unless someone objects, this issue is at consensus. 7197 This was discussed in the "Comments 21-30" thread: Comment #21. This 7198 is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry 7199 timer" thread. 7201 3.41. Handling of Event 14 in the Connect State 7203 Status: Consensus 7204 Change: Yes 7205 Summary: Make event 14 optional. 7207 Discussion: 7209 Siva opened the discussion with: 7211 > If the transport connection receives an indication > that is 7212 invalid or unconfigured. [Event 14]: > - the TCP connection is 7213 rejected. 7215 I don't understand how we would get this event while in this state. 7217 Sue replied: 7219 See my earlier comments (1-10) on the connection state. It happens 7220 in implementations which track the TCP state more closely. I suggest 7221 that Event 14 become optional. 7223 Sue also suggested we fold this into the discussion about events 7224 13-17, which is tracked in issue 13.4. 7226 Sue proposed: 7228 My resolution: Let event 14 be optional. Not all BGP implementations 7229 support it. 7231 And asked if this let us reach consensus on this issue. 7233 Siva agreed with this, we are at consensus on this. 7235 This was discussed in the "Comments 21-30" thread: Comment #22. This 7236 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7238 3.42. Handling events 20, 21 in the Connect State and Active State 7240 Status: Consensus 7241 Change: Yes 7242 Summary: Use the text Tom proposed in the discussion section. 7244 Discussion: 7246 Siva began this with: 7248 We need to consider the case where we receive events 20 (message 7249 header error) and 21 (Open message error) when the delay timer is 7250 running. 7252 Since the connection has been established at this point, we need to 7253 send a Notification message and then terminate the connection. 7255 To which Sue replied: 7257 Alternative comments: 7259 1) We have not sent an Open statement. 2) Why do we have to send an 7260 Notification? I see no justification for it. 7262 Suggestion: Do you have implementations that send notification? Do 7263 you know of others that don't. 7265 Jeff saw this as indicative of an issue with section 4.2 the way it 7266 is currently written: 7268 >From section 4.2 of -18: .in 4 4.2 OPEN Message Format 7270 .in 7 After a TCP is established, the first message sent by each side 7271 is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE 7272 message confirming the OPEN is sent back. Once the OPEN is 7273 confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be 7274 exchanged. 7276 This text implies that NOTIFICATIONs can only be sent once we have 7277 sent an open and then a keepalive, generally meaning we're in the 7278 Established state. 7280 Anyone suggestions for modifying the wording? 7282 Section 6.1 (Message header error) is one situation that implies that 7283 a NOTIFICATION can be sent without sending even an OPEN message. 7284 Note that since the base FSM implies that we send an OPEN message 7285 immediately when we have a completed transport connection, we SHOULD 7286 be in at least OpenSent. However, the DelayOpen timer means that we 7287 MAY send a NOTIFICATION when we are in the Connect state. 7289 GateD, at least, will not send a NOTIFICATION without first sending 7290 an OPEN. 7292 We need to pick one: You can send NOTIFICATIONS before OPEN or before 7293 OPEN if the OpenDelay timer is running. However, we MUST fix the 7294 text above. 7296 Tom opined: 7298 .in 4 A NOTIFICATION without a preceding OPEN is rather hard to 7299 interpret; it is the OPEN that gives the recipient what it needs to 7300 know about its potential peer (Version, AS number, ID, options etc) 7301 so it makes sense to send an OPEN even if it is followed by a 7302 NOTIFICATION to say goodbye :-( as opposed to a KEEPALIVE which says 7303 hello:-). 7305 But as ever, what is implemented? 7307 Yakov suggested these modifications to the text to resolve this: 7309 .in 4 1. Delete the last sentence in the above paragraph 7311 or 7313 2. Delete "and NOTIFICATION" in the last sentence in the above 7314 paragraph 7316 Jeff replied that he preferred the first option, and that the second 7317 could be interpreted as NOTIFICATIONs not being legal, when, in fact, 7318 they may. 7320 So the text on the table to resolve this is: 7322 4.2 OPEN Message Format 7324 .in 7 After a TCP is established, the first message sent by each side 7325 is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE 7326 message confirming the OPEN is sent back. 7328 However, this does not entirely clear up the original point about the 7329 FSM. If we receive an error in Connect/Active, do we send a NOTIFY? 7330 Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in 7331 immediate succession? 7333 Sue replied: 7335 .in 4 I suggest we don't send a "NOTIFICATION" when Event 20 or Event 7336 21 is received in Connect or Active state. 7338 Tom responded to this issue with: 7340 .in 4 Issue 42 queries whether or not we can send a NOTIFICATION when 7341 we have not successfully exchanged OPENs. I propose we should, 7342 following the suggestions of Jeff and Yakov. 7344 As Yakov suggested, this requires the removal of the second sentence, 7345 first paragraph, of 4.2 which implies a NOTIFICATION can only be sent 7346 after a successful exchange of OPENs. I think this fits best with 7347 the other references to the uses of NOTIFICATION in the draft. 7349 In terms of the FSM, it means that in Connect and Active states, on 7350 receipt of events 20 or 21, we should send a NOTIFICATION so that the 7351 last section starting 7353 In response to any other event............. 7355 is replaced by (and noting we have agreed to drop references to MIB 7356 actions) 7358 If the BGP message header checking or OPEN message checking detect an 7359 error (see Section 6.2) [Events 20 or 21], the local system: - sends 7360 a NOTIFICATION message with the appropriate error code, - resets the 7361 connect retry timer (sets to zero), - releases all BGP resources, - 7362 drops the TCP connection - increments the ConnectRetryCnt (connect 7363 retry count) by 1, - [optionally] performs peer oscillation damping - 7364 and goes to the Idle state. In response to any other event (Events 7365 7-8, 10-11,18, 22-27), the local system: - resets the connect retry 7366 timer (sets to zero), - releases all BGP resources, - drops the TCP 7367 connection, - increments the ConnectRetryCnt (connect retry count) by 7368 one, - [optionally] performs peer oscillation damping, - and goes to 7369 the Idle state 7370 .in 4 (Note that this text is not quite watertight. Suppose we are 7371 in Active state, having been started with CRT running, receive an SYN 7372 (event 13), send SYN-ACK and then get a malformed message (events 7373 20/21). We have not yet received an ACK and so should not send 7374 anything over TCP; I would expect TCP to buffer this awaiting the ACK 7375 except we then take down the TCP connection - or try to; I don't know 7376 what happens next but regard it as sufficiently obscure not to be 7377 concerned). 7379 (My other concern is greater; why do we now not send NOTIFICATIONs 7380 for other events; in Open Sent, Open Confirm or Established, we send 7381 one for the 'default event list' so what makes events 20 and 21 in 7382 Active and Connect so special? I can justify the absence of a 7383 NOTIFICATION for events 7, 8, 10, 11, 18, 22 since there is no 7384 evidence of a TCP connection to send it on; but events 23-27 in 7385 Active or Connect say we have received an erroneous message, the TCP 7386 connection is there so why not send a NOTIFICATION? Event7: 7387 Automatic stop Event8: Idle hold timer expires Event10: Hold timer 7388 expires Event11: Keepalive timer expires Event18: BGPOpen Event22: 7389 Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg 7390 Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr 7392 Sue accepted Tom's text, so barring any objections, we are at 7393 consensus on this. 7395 This was discussed in the "Comments 21-30" thread: Comment #23. This 7396 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and 7397 the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread. 7399 3.43. Handling the default events in the Connect state 7401 Status: No Consensus 7402 Change: Potentially 7403 Summary: Add text at the end of the discussion. 7405 Discussion: 7407 Siva opened this with: 7409 .in 4 The Open Delay timer [original: BGP Delay Open Timers) needs to 7410 be cleared if it is running. 7412 How about adding this: 7414 % - If the ConnectRetry Timer is running % - Clear the Connect Retry 7415 timer % - Otherwise % - Clear the Open Delay timer [original: BGP 7416 Delay Open Timer] 7417 Sue replied that: 7419 By the default you mean the text: 7421 In response to any other events[Events 7-8, 10-11, 18, 20-27], the 7422 local system: 7424 "resets" to me implies stops and clears. I think the text is clear 7425 than the text above. ------------ Is this the replacement text you 7426 imply above: - resets the connect retry timer (sets to zero), - 7427 clears the Open Delay timer [original: BGP Delay timer] (sets to 7428 zero), - increments the ConnectRetryCnt (connect retry count) by 1, - 7429 [optionally] performs bgp peer oscillation damping, and - goes to 7430 Idle text: 7432 Editor's note: various incarnations of "Open Delay timer" have been 7433 replaced with "Open Delay timer". See issue 7. 7435 Sue replied that she accepted Siva's changes with these editorial 7436 changes: 7438 old text: - resets the connect retry timer (sets to zero) - clears 7439 the open delay timer 7441 new text: - if the connect retry timer is running, clear the connect 7442 retry timer (set to zero). - if the open delay timer is running, 7443 clear the open delay timer (set to zero). 7445 Since the substantive changes have been accepted, unless someone 7446 objects, this issue is at consensus. 7448 This was discussed in the "Comments 21-30" thread: Comment #24. This 7449 was also brought up in the "BGP-19: Issue 34-35, 40-48" 7451 3.44. Handling Event 23 in Connect and OpenSent 7453 Status: Consensus 7454 Change: Yes 7455 Summary: Adopt text at the end of the discussion section. 7457 Discussion: 7459 This began with Siva saying: 7461 .in 4 This is currently being handled in the default event processing 7462 section. However, we do not need to go through the peer oscillation 7463 damping process in this case. Can we change the wordings to reflect 7464 this, or move this out of peer oscillation damping processing ? 7465 Sue replied: 7467 1) There is no default event handling process in the text, you will 7468 need to specify the text. 7470 2) The state table below (hares-statemt-03.txt) states shows the 7471 changes 7473 ------------- 7474 Event 23 7475 states: 7476 current Idle Connect Active Open-Sent Open-Cnf Establish 7477 ------------------------------------------------- 7478 next state Idle Idle Idle Idle Idle Idle 7479 ------------------------------------------------- 7480 action V D D Y Y T ================================================= 7482 V - Indicate FSM errors and ignore. D - 1) resets the connect retry 7483 timer (sets to zero), 2) drops the TCP connection, 2) releases all 7484 BGP resources, 3) increments the ConnectRetryCnt (connect retry 7485 count) by 1, 4) [optionally] performs the bgp peer oscillation 7486 damping, and Goes to Idle state. Y 1) resets the connect retry timer 7487 (sets to zero), 2) Drops the TCP connection, 3) releases all BGP 7488 resources, 4) [optionally] 7490 In an exchange between Siva and Sue, this came up: 7492 Siva: 7494 "Default event handling" was perhaps a poor choice of words. 7496 What I meant is this 7498 .in 4 Event 23 (Notify Message Version error) only indicates a 7499 version mismatch. By going through action sequence D, we will be 7500 performing peer oscillation damping. Should we perform damping, 7501 since this is not really a cause for persistent oscillation ? 7503 Also, since we have a distinct event to indicate a version error 7504 event, can include text indicating that version negotiation 7505 processing should take place upon receipt of this event ? 7507 Sue: 7509 Yes, we can change the "D" in state machine to a "y". 7511 The issue is what if Connect state occurs and there is not a TCP 7512 connection. Should an OPEN with wrong version be accepted? If the 7513 Open Delay flag is off, the connection state should not be getting an 7514 Open. The "D" action below works for "open delay flag off". 7516 The "y" action you suggest can occur if the open delay timer is on. 7518 If this is the issue, please confirm. 7520 We could say: if open delay flag is on -> y action if open delay flag 7521 is off -> D action 7523 Please let me know if this is the concern, and suggest text. 7525 Prior to this exchange, this issue was at consensus. The only thing 7526 that is firm in this exchange is changing "D" to "y". There seems to 7527 be some open discussion still, so we'll reopen it. 7529 After some discussion, this is the text we have settled on: 7531 If a NOTIFICATION message is received with a version error[Event24], 7532 the local system checks the Open Delay timer. If the Open Delay 7533 timer is running, the local system: - resets the connect retry timer 7534 (sets to zero), - stops and reset the Open Delay timer (sets to zero, 7535 - releases all BGP resources, - drops the TCP connection, - changes 7536 its state to Idle. If the Open Delay timer is not running, the local 7537 system: - resets the connect retry timer (sets to zero), - releases 7538 all BGP resources, - drops the TCP connection, - increments the 7539 ConnectRetryCnt (connect retry count) by 1, - optionally performs 7540 peer oscillation damping, and - changes its state to Idle. 7542 N.B. This is now event 24 (see issue 26). 7544 We are at consensus with this. 7546 This was discussed in the "Comments 21-30" thread: Comment #25. This 7547 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7549 3.45. Event 17 in the Connect state 7551 Status: Consensus 7552 Change: Yes 7553 Summary: Adopt text at the end of the discussion section. 7555 Discussion: 7557 This began with Siva asking: 7559 .in 4 If the transport connection fails (timeout or transport 7560 disconnect) [Event17], the local system: - changes its state to 7561 Active. 7563 If the transport connection fails when the Open Delay timer 7564 [original: BGP Open Delay timer] is running, should we still be going 7565 into the Active state ? 7567 Sue replied referring to the discussion tracked in issue 13.4. 7569 Jeff responded that: 7571 .in 4 In this particular case, I think the issue is separate from the 7572 issues for events 13-17 since this isn't particular to how deep the 7573 BGP implementation meddles in the TCP implementation. 7575 If we are in the Connect state, because we have an incoming transport 7576 connection that has completed, but we have the OpenDelay timer 7577 running and the transport connection is closed, we can simply drop 7578 into Active after resetting the ConnectRetry timer and clearing the 7579 OpenDelay timer (if set/exists). In the case of an unconfigured 7580 peer, we can discard the FSM instance. 7582 Tom replied that he agreed with this. 7584 Tom then proposed this text: 7586 If the TCP connection fails[Event 17] and the Open Delay timer is 7587 running, the local system: - restarts the connect retry timer, - 7588 clears the Open Delay timer - continues to listen for a connection 7589 that may be initiated by the remote BGP peer, and - changes its state 7590 to Active. 7592 If the TCP connection fails [Event17] and the Open Delay timer is not 7593 running, the local system: - drops the TCP connection, - releases all 7594 BGP resources, - sets ConnectRetryCnt (the connect retry count) to 7595 zero - resets the connect retry timer (sets to zero), and - goes to 7596 Idle state. 7598 to replace If the TCP connection fails (timeout or disconnect) 7599 [Event17], the local system: - restarts the connect retry timer, - 7600 continues to listen for a connection that may be initiated by the 7601 remote BGP peer, and - changes its state to Active. 7603 Sue agreed to change the text to reflect the comments. 7605 Jeff brought out a couple of other concerns, and Tom replied: 7607 > If the TCP connection fails [Event17] and the Open Delay > timer is 7608 not running, the local system: > - drops the TCP connection, > - 7609 releases all BGP resources, 7611 .in 4 There are no resources to release while in the connect state. 7612 (Unless we're using this as shorthand for something else - I forget.) 7614 Tom: 7616 .in 4 I was unsure about this action. It is present for Active state 7617 event 17 which is why I put it in, it does include sub-actions such 7618 as clear Open Delay timer (not running), clear Connect Retry timer 7619 (could be running) so I think it right to play safe and include it. 7621 Jeff: 7623 > - sets ConnectRetryCnt (the connect retry count) to zero 7625 I'm forgetting if this action is consistent with everything else. I 7626 don't have a current copy of the FSM and I don't trust -18 to be 7627 current enough. :-) This said, why do we go to zero? I could see not 7628 incrementing it and letting the normal decay process deal with it. 7629 The same would apply for the above. 7631 Tom: 7633 .in 4 Again, I was unsure about this so put it in and waited for 7634 comment. I have a chart of 27 events and 6 states in which I have 7635 colored in the connect retry and peer oscillation damping actions and 7636 it looks like measles; I could not divine the underlying logic. 7637 Incrementing the connect retry count would make as much if not more 7638 sense to me. (It is zeroed for Manual Stop). 7640 But the action '[optionally] perform peer oscillation damping' is yet 7641 more erratic (eg for event 10 - Hold Timer expired - it is performed 7642 exiting Connect, Active, Established but not Open Confirm or Open 7643 Sent) so I left it out. Again, it might make more sense put it in. 7645 Sue replied to this: 7647 The connect state could have a few resources (minimum peer footprint) 7648 as the FSM goes from Idle to Connected state. While this amount of 7649 BGP resources is not as much as the final amount, it still needs to 7650 get released. 7652 2nd - I think the ConnectRetry count should be removed; Thanks for 7653 catching that. 7655 Please confirm that part #1 is OK with you so we can put issue 45 7656 into consensus state. 7658 Sue accepted Tom's solution, for the following text: 7660 If the TCP connection fails [Event18], the local system checks the 7661 Open Delay Timer. If the Open Delay timer is running, the local 7662 system: - restarts the connect retry timer, - stops the Open Delay 7663 timer and resets value to zero, - continues to listen for a 7664 connection that may be initiated by the remote BGP peer, and - 7665 changes its state to Active. If the open Delay timer is not running, 7666 the local system: - resets the connect retry timer (sets to zero), 7667 and - Drops the TCP connection, - Releases all BGP resources, - and 7668 goes to Idle State. 7670 N.B. This is now event 18 (see issue 26). 7672 We are at consensus with this. 7674 This was discussed in the "Comments 21-30" thread: Comment #26. This 7675 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7677 3.46. Handling of Event 17 in Active state 7679 Status: Consensus 7680 Change: No 7681 Summary: See issue 13.4, this issue closed in favor of that one. 7683 Discussion: 7685 This began with Siva saying: 7687 We should now move into Idle state. Can we add 7689 % - Goes to Idle state 7691 Sue replied that she thought this should be bundled in with the issue 7692 tracked in 13.4. Since no one objected, this issue has been closed 7693 in favor of that one. 7695 This was discussed in the "Comments 21-30" thread: Comment #27. 7697 3.47. Handling of Event 19 in Active state 7699 Status: Consensus 7700 Change: Yes 7701 Summary: Add the new text in the discussion section. 7703 Discussion: 7705 This began with Siva suggesting: 7707 > - Set the Hold timer to a large value (4 minutes), Since OPEN 7708 messages have been exchanged, can we change this to - If the 7709 negotiated Hold time is not 0, set the Hold time to - the negotiated 7710 value 7712 Sue replied that: 7714 The text in Active and Open Sent needs to be the same. The text in 7715 Open Sent is: - sets the Hold timer according to the negotiated value 7716 (see section 4.2), and 7718 Which text do you prefer? 7720 Sue replied that this text would be added to the next draft: 7722 New text 7724 - if the hold timer value is non-zero, - starts the keepalive timer 7725 to initial value, - resets the hold timer to the negotiated value, - 7726 else if the hold timer is zero - resets the keepalive timer (set to 7727 zero), - resets the hold timer to zero. 7729 This seems to address Siva's concerns, this issue is at consensus, if 7730 there are objections, we can reopen it. 7732 This was discussed in the "Comments 21-30" thread: Comment #28. This 7733 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7735 3.48. Handling of Event 2 in Active state 7737 Status: Consensus 7738 Change: Yes 7739 Summary: Update the draft with the text at the end of the discussion 7740 section. 7742 Discussion: 7744 Siva opened with: 7746 > A manual stop event[Event2], the local system: > - Sends a 7747 notification with a Cease, > - drops the Transport connection 7749 These two actions are possible only if a transport connection had 7750 already been established. How about changing the text to 7752 % - If a transport connection had been successfully established % - 7753 Send a Notification with a Cease % - Drop the Transport Connection 7754 Sue counter suggested: 7756 A manual stop event [Event 2], the local system - Drop the TCP 7757 connection, - Release all BGP resources, - resets the connection 7758 retry timer [sets to zero], - goes to Idle. 7760 Jeff replied: 7762 I'm rather confused. Under exactly what circumstances can we be in 7763 the Active state and have an active TCP connection at all? Ditto for 7764 having any BGP resources? 7766 Going to Idle is fine. 7768 Tom offered this example: 7770 eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK 7771 received, Delay Open flag set and there we are. Most events are now 7772 possible either from a well-implemented remote peer or a badly 7773 implemented remote peer. 7775 Sue asked if there were any additional comments, if not, the text 7776 will be: 7778 A manual stop event[Event2], the local system: - Sends a NOTIFICATION 7779 with a Cease, - releases all BGP resources including - stopping the 7780 Open delay timer - drops the TCP connection, - sets ConnectRetryCnt 7781 (connect retry count) to zero - resets the connect retry timer (sets 7782 to zero), - changes its state to Idle. 7784 There have been no additional comments, we will use the text Sue 7785 proposed. 7787 This was discussed in the "Comments 21-30" thread: Comment #29. This 7788 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7790 3.49. Default Event handling in Active state 7792 Status: Consensus 7793 Change: No 7794 Summary: No routes in active. 7796 Discussion: 7798 Siva began with: 7800 To ensure consistency with E2 handling, can we add 7801 % - If any BGP Routes exist, delete the routes 7803 Sue replied: 7805 Comment: Yakov and Jeff noted, there are no routes in Active state. 7807 Since there were no responses disagreeing, we'll consider this closed 7808 unless someone wants to open it back up. 7810 This was discussed in the "Comments 21-30" thread: Comment #30. 7812 3.50. Clearing Hold timer in OpenSent, OpenConfirm and Established 7813 State 7815 Status: Consensus 7816 Change: No 7817 Summary: This issue is addressed in the "Clear BGP resources" 7819 Discussion: 7821 This began with Siva stating: 7823 .in 4 In all event handling where we go to Idle state, we need to 7824 clear the Hold Timer as well. 7826 Sue replied that: 7828 issue resolve one way last Jan - March Clearing of keep alive timer 7829 included in Clear BGP resources 7831 No response to this yet, but since this seems to be resolved it is at 7832 consensus unless someone objects. 7834 This was discussed in the "Comments 30-36" thread: Comment #31. 7836 3.51. Clearing Keepalive timer in OpenConfirm and Established State 7838 Status: Consensus 7839 Change: No 7840 Summary: This issue is addressed in the "Clear BGP resources" 7842 Discussion: 7844 This began with Siva stating: 7846 .in 4 In all event handling where we go to Idle state, we need to 7847 clear the Keepalive Timer as well. 7849 Sue replied that: 7851 issue resolve one way last Jan - March Clearing of keep alive timer 7852 included in Clear BGP resources 7854 No response to this yet, but since this seems to be resolved it is at 7855 consensus unless someone objects. 7857 This was discussed in the "Comments 30-36" thread: Comment #32. 7859 3.52. Handling Event 18 in the OpenSent state (Keepalive Timer) 7861 Status: Consensus 7862 Change: Yes 7863 Summary: Make the event optional. 7865 Discussion: 7867 This began with Siva asking: 7869 .in 4 Why do we start the Keepalive timer at this stage ? Isn't it 7870 sufficient to do so when we move into Established state ? 7872 Sue replied: 7874 An earlier comment from Tom (and you) requested the following: 7876 <--Open [Open sent state] 7878 Open--> [Event 18] 7880 <---Open <---Keepalive [Action from Event 18 in Open Sent] [Open 7881 Confirm] Keepalive -> [Event 25] [established] 7883 What do implementations do? We'll have to query implementations. 7885 Jeff added: 7887 I'm assuming the second OPEN going from right to left is a typo. If 7888 it isn't, thats a FSM error to the peer on the left. 7890 Theoretically, an implementation that utilizes its keepalive timer to 7891 send the first keepalive to transition to Established is still 7892 interoperable. However: 7894 o Keepalives can be disabled by negotiating hold time of zero o We 7895 really shouldn't need to restart the Keepalive timer. If there is a 7896 delay in the keepalive that transitions from OpenConfirm to 7897 Established, its due to the transport connection. It should be 7898 reliable and it *should* get through. If it doesn't, there's other 7899 problems and the hold timer for the peer on the right should do the 7900 Right Thing and drop the connection. 7902 > What do implementations do? We'll have to query implementations. 7904 .in 4 GateD at least waits to enter the Established state prior to 7905 starting the KeepAlive timer. 7907 Tom also added: 7909 .in 4 My comment was that if we do not send a KeepAlive (and start 7910 the KeepAlive timer), on exiting from Active with Event 19 to 7911 OpenConfirm then we never will and the connection will die. Open 7912 Confirm state means valid Open received so we must send a KeepAlive 7913 to acknowledge the Open (as pointed out in Jeff's other posting) and 7914 we never do it in OpenConfirm state itself (unless the KeepAlive 7915 timer expires which it cannot because we have not started it). 7917 So for me, OpenSent state Event 18 was and is correct, sending the 7918 KeepAlive without which the connection goes no further and Active 7919 state Event 19 needs to be brought into line. 7921 To say that the timer is started when entering Established state is 7922 fine except for a slight problem; we have no way in this FSM of 7923 defining actions that are taken on entering a state, only actions to 7924 be taken on leaving another state so that is why the KeepAlive 7925 actions need to be where they are (or are not in the case of Active 7926 state Event 19). 7928 Sue replied, asking more implementors to chime in on what they do for 7929 this part of the FSM. 7931 Curtis replied that we should: 7933 .in 4 Make it optional. Timing out in open or open-sent has never 7934 been much of an issue, so whether one or three keepalive get sent 7935 shouldn't be a hot topic. 7937 Sue said that this was fine, and she would work on text specifying 7938 optional. 7940 Jeff replied regarding GateD's behavior: 7942 .in 4 GateD will start its keepalive timer while in this state, so 7943 multiple keepalives will be sent. 7945 As someone previously said, this is a "yawn" issue. But to choose 7946 one way or the other, we may potentially make someone in non- 7947 compliance. 7949 From the closure of issue 12, we have this text, which discusses 7950 Keepalives to consider in relation to the other keepalive issue here: 7952 Change 1: new text 7954 Active state - event 19 7956 If an Open is received with the Open Delay timer is running [Event 7957 19], the local system - clears the connect retry timer (cleared to 7958 zero), - stops and clears the Open Delay timer - completes the BGP 7959 initialization, - stops and clears the Open Delay timer - sends an 7960 OPEN message, - send a Keepalive message, - if the hold timer value 7961 is non-zero, - starts the keepalive timer to initial value, - resets 7962 the hold timer to the negotiated value, else if the hold timer is 7963 zero - resets the keepalive timer (set to zero), - resets the hold 7964 timer to zero. 7966 - changes its state to OpenConfirm. 7968 .in 7 If the value of the autonomous system field is the same as the 7969 local Autonomous System number, set the connection status to an 7970 internal connection; otherwise it is "external". 7972 Since there were no more comments, this is at consensus. 7974 This was discussed in the "Comments 30-36" thread: Comment #33. And 7975 in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State 7976 (Keepalive timer set)" thread. 7978 3.53. Established State MIB 7980 Status: Consensus 7981 Change: No 7982 Summary: MIB references pulled in favor of having them in the MIB 7983 document. See issue 8. 7985 Discussion: 7987 This began with Siva asking: 7989 .in 4 Some event handling in the Established state do not set the MIB 7990 Reason when handling an event that causes an error. Can we add this 7991 ? 7992 Sue replied that we have pulled the MIB wording from the FSM. See 7993 issue 8. 7995 This was discussed in the "Comments 30-36" thread: Comment #34. 7997 3.54. State impact of not supporting Optional Events 7999 Status: Consensus 8000 Change: Yes 8001 Summary: Add the text at the end of the discussion section. 8003 Discussion: 8005 Siva stated that: 8007 .in 4 For the events whose status is optional, can we state the 8008 impact of not supporting them (in terms of any interoperability 8009 issues). I understand that most of the optional events will not have 8010 such an impact; but a clarification statement for the optional events 8011 would benefit new implementors. 8013 Sue responded: 8015 Much of the support of optional parameters depends on policy. I 8016 could put a short note about the optional events and parameters as 8017 part of 8.1.5 or 8.2.1.3 8019 I think it fits better in 8.1.5. Optional: Events: 3-8, 12, 13-14[my 8020 suggestion] 19, 22 Timers: Idle Hold Timer Open Delay Timer 8022 Required flags for optional parameters: Open Delay Flag BGP Stop Flap 8024 Sue said she would try to work up more if it is agreed that this is 8025 on the right track. 8027 Sue provided this text to clarify the behavior associated with 8028 Optional Attributes: 8030 8.2.1.3 FSM and Optional Attributes 8032 Optional Attributes specify either flags that augment the normal 8033 processing of the BGP FSM, or optional timers. If a Optional 8034 attribute can be set on a system, the Events and the BGP FSM actions 8035 must be support. For example, if the following options can be set in 8036 a BGP implementation: AutoStart and Passive TCP connection 8037 Establishment flag, then the events 3, 4 and 5 must be supported. 8039 If an Optional attribute cannot be set (that is declared always off 8040 logically), the events supporting that set of options do not have to 8041 be supported. 8043 This was discussed in the "Comments 30-36" thread: Comment #35. 8045 3.55. New DelayOpen State 8047 Status: Consensus 8048 Change: No 8049 Summary: We've chosen not to reopen the debate about adding a 8050 DelayOpen State to the FSM. 8052 Discussion: 8054 Siva began with asking: 8056 .in 4 Is delaying the sending of an OPEN message a standard industry 8057 practice ? 8059 Also, in the FSM, this has been handled by practically implementing a 8060 sub-state each, within the CONNECT and ACTIVE states. Won't the FSM 8061 look more simple if we just had a new DelayOpen state that we could 8062 move into ? 8064 Sue responded that this was something we have tried to do before, but 8065 that it spawned some degree of rabid response on both sides. Given 8066 our current mandate to stick with what is implemented, it is probably 8067 best not to reopen this debate. 8069 Unless someone badly wants to reopen this debate, the issue is at 8070 Consensus. 8072 This was discussed in the "Comments 21-30" thread: Comment #22. 8073 This was discussed in the "Comments 21-30" thread: Comment #26. 8074 This was discussed in the "Comments 30-36" thread: Comment #36. 8076 3.56. Clarify what is covered in the base document 8078 Status: Consensus 8079 Change: Yes 8080 Summary: Add the text at the end of the discussion to clarify what is 8081 documented where with regard to BGP and its extensions. 8083 Discussion: 8085 This grew out of a discussion on how to use BGP Identifiers in an 8086 IPv6-only environment. In that discussion it became clear that the 8087 way the documents are currently structured it is not clear to new 8088 readers that extension specifications can and do specify behavior 8089 that supersedes the behavior specified in the base spec. To that end 8090 it was agreed that this text should be added: 8092 .in 5 This document specifies the base behavior of the BGP protocol. 8093 This behavior can and is modified by extension specifications. When 8094 the protocol is extended the new behavior is fully documented in the 8095 extension specifications. 8097 This was discussed in the "Next-Hop in IPv6 only environments" 8098 thread. 8100 4. Security Considerations 8102 This document is an informational document that discusses the changes 8103 made in revising the BGP-4 specification. There are no security 8104 considerations applicable to this document. 8106 5. Normative References 8108 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 8109 (BGP-4)", RFC 1771, March 1995. 8111 Author's Address 8113 Andrew S. Lange 8114 Alcatel-Lucent 8116 Email: andrew.lange@alcatel-lucent.com