idnits 2.17.1 draft-ietf-idr-bgp-issues-05.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 512: '...mentation of BGP MUST allow the Hold T...' RFC 2119 keyword, line 513: '...onfigurable, and MAY allow the other t...' RFC 2119 keyword, line 557: '...tter random value MAY be configurable....' RFC 2119 keyword, line 592: '...mentation of BGP MUST allow the Hold T...' RFC 2119 keyword, line 593: '...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 11, 2011) is 4642 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 937, but not defined == Missing Reference: 'RWStevens' is mentioned on line 1308, but not defined == Missing Reference: 'RFC2385' is mentioned on line 4091, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Missing Reference: 'RFC2918' is mentioned on line 1704, but not defined == Missing Reference: 'RFC2842' is mentioned on line 1734, but not defined ** Obsolete undefined reference: RFC 2842 (Obsoleted by RFC 3392) -- Looks like a reference, but probably isn't: '1' on line 1839 == Missing Reference: 'RFC904' is mentioned on line 6122, but not defined -- Looks like a reference, but probably isn't: '12' on line 3040 -- Looks like a reference, but probably isn't: '10' on line 4080 == Missing Reference: 'RFC793' is mentioned on line 4088, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) -- Looks like a reference, but probably isn't: '13' on line 4643 == Missing Reference: 'Event 9' is mentioned on line 5208, but not defined == Missing Reference: 'Event17' is mentioned on line 7610, but not defined == Missing Reference: 'Event 18' is mentioned on line 7881, but not defined == Missing Reference: 'Event 19' is mentioned on line 5058, but not defined == Missing Reference: 'Event 14' is mentioned on line 7215, but not defined == Missing Reference: 'Event 13' is mentioned on line 5800, but not defined == Missing Reference: 'Event 17' is mentioned on line 7589, but not defined == Missing Reference: 'Event 22' is mentioned on line 5809, but not defined == Missing Reference: 'Event 15' is mentioned on line 5801, but not defined == Missing Reference: 'RFC3065' is mentioned on line 5962, but not defined ** Obsolete undefined reference: RFC 3065 (Obsoleted by RFC 5065) == Missing Reference: 'Event 1' is mentioned on line 6673, but not defined == Missing Reference: '3-6' is mentioned on line 6679, but not defined == Missing Reference: 'Event1' is mentioned on line 6679, but not defined == Missing Reference: 'Events 7-8' is mentioned on line 7424, but not defined == Missing Reference: '10-11' is mentioned on line 7424, but not defined -- Looks like a reference, but probably isn't: '18' on line 7424 == Missing Reference: '20-27' is mentioned on line 7424, but not defined == Missing Reference: 'Event24' is mentioned on line 7534, but not defined == Missing Reference: 'Event18' is mentioned on line 7663, but not defined == Missing Reference: 'Event2' is mentioned on line 7781, but not defined == Missing Reference: 'Event 2' is mentioned on line 7759, but not defined == Missing Reference: 'Event 25' is mentioned on line 7884, but not defined == Unused Reference: 'RFC1771' is defined on line 8111, 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 11, 2011 5 Expires: February 12, 2012 7 Issues in Revising BGP-4 (RFC1771 to RFC4271) 8 draft-ietf-idr-bgp-issues-05 10 Abstract 12 This document records the issues discussed and the consensus reached 13 in the Interdomain Routing (IDR) Working Group during its efforts to 14 revise and bring up to date the base specification for the BGP-4 15 protocol as documented in RFC1771. The document focuses on the 16 changes tracked from August 2002 when the last major push for 17 revision began. The results of these efforts are encoded in RFC4271, 18 which should be taken as normative for any of the issues that were 19 discussed. The discussion here is intended to record how and why 20 some of the changes to BGP were made. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 12, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2. The Issues from -17 to -18 . . . . . . . . . . . . . . . . . 6 58 2.1. IDR WG Charter . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.3. FSM wording for what state BGP accepts connections in . . 8 61 2.4. BGP Identifier/Router ID . . . . . . . . . . . . . . . . 8 62 2.5. Direct EBGP Peers . . . . . . . . . . . . . . . . . . . . 8 63 2.6. Disallow Private Addresses . . . . . . . . . . . . . . . 9 64 2.7. Renumber Appendix Sections . . . . . . . . . . . . . . . 9 65 2.8. Jitter Text . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.9. Reference to RFC904 - EGP Protocol . . . . . . . . . . . 14 67 2.10. Extending AS_PATH Attribute . . . . . . . . . . . . . . . 14 68 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 69 9.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 2.11.1. Rules for routes from Loc-RIB to Adj-RIB-Out - 71 Section 9.1.3 . . . . . . . . . . . . . . . . . . . 18 72 2.11.2. Rules for routes from Loc-RIB to Adj-RIB-Out - 73 Section 2 . . . . . . . . . . . . . . . . . . . . . 19 74 2.11.3. Documenting IBGP Multipath . . . . . . . . . . . . . 21 75 2.12. TCP Behavior Wording . . . . . . . . . . . . . . . . . . 25 76 2.13. Next Hop for Originated Route . . . . . . . . . . . . . . 25 77 2.14. NEXT_HOP to Internal Peer . . . . . . . . . . . . . . . . 26 78 2.15. Grammar Fix . . . . . . . . . . . . . . . . . . . . . . . 26 79 2.16. Need ToC, Glossary and Index . . . . . . . . . . . . . . 27 80 2.17. Add References to other RFC-status BGP docs to base 81 spec . . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 2.18. IP Layer Fragmentation . . . . . . . . . . . . . . . . . 27 83 2.19. Appendix Section 6.2: Processing Messages on a Stream 84 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 28 85 2.20. Wording fix in Section 4.3 . . . . . . . . . . . . . . . 29 86 2.21. Authentication Text Update . . . . . . . . . . . . . . . 29 87 2.22. Scope of Path Attribute Field . . . . . . . . . . . . . . 30 88 2.23. Withdrawn and Updated routes in the same UPDATE message . 31 89 2.24. Addition or Deletion of Path Attributes . . . . . . . . . 32 90 2.25. NEXT_HOP Semantics . . . . . . . . . . . . . . . . . . . 33 91 2.26. Attributes with Multiple Prefixes . . . . . . . . . . . . 34 92 2.27. Allow All Non-Destructive Messages to Refresh Hold 93 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . 34 94 2.28. BGP Identifier as Variable Quantity . . . . . . . . . . . 35 95 2.29. State Why Unresolveable Routes Should Be Kept in 96 Adj-RIB-In . . . . . . . . . . . . . . . . . . . . . . . 35 97 2.30. Mention Other Message Types . . . . . . . . . . . . . . . 36 98 2.31. Add References to Additional Options . . . . . . . . . . 37 99 2.32. Clarify EGP Reference . . . . . . . . . . . . . . . . . . 37 100 2.32.1. EGP ORIGIN Clarification . . . . . . . . . . . . . . 38 101 2.32.2. BGP Destination-based Forwarding Paradigm . . . . . 42 102 2.33. Add "Optional Non-Transitive" to the MED Section . . . . 46 103 2.34. Timer & Counter Definition . . . . . . . . . . . . . . . 46 104 2.35. Fix Typo . . . . . . . . . . . . . . . . . . . . . . . . 47 105 2.36. Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary . 47 106 2.37. Combine "Unfeasible Routes" and "Withdrawn Routes" . . . 47 107 2.38. Clarify Outbound Route Text . . . . . . . . . . . . . . . 49 108 2.39. Redundant Sentence Fragments . . . . . . . . . . . . . . 50 109 2.40. Section 9.2.1.1 - Per Peer vs. Per Router 110 MinRouteAdvertisementInterval . . . . . . . . . . . . . . 51 111 2.41. Mention FSM Internal Timers . . . . . . . . . . . . . . . 51 112 2.42. Delete the FSM Section . . . . . . . . . . . . . . . . . 52 113 2.43. Clarify the NOTIFICATION Section . . . . . . . . . . . . 52 114 2.44. Section 6.2: OPEN message error handling . . . . . . . . 53 115 2.45. Consistent References to BGP Peers/Connections/Sessions . 55 116 2.46. FSM Connection Collision Detection . . . . . . . . . . . 56 117 2.47. FSM - Add Explicit State Change Wording . . . . . . . . . 58 118 2.48. Explicitly Define Processing of Incoming Connections . . 58 119 2.49. Explicitly Define Event Generation . . . . . . . . . . . 62 120 2.50. FSM Timers . . . . . . . . . . . . . . . . . . . . . . . 63 121 2.51. FSM ConnectRetryCnt . . . . . . . . . . . . . . . . . . . 63 122 2.52. Section 3: Keeping routes in Adj-RIB-In . . . . . . . . . 64 123 2.53. Section 4.3 - Routes v. Destinations - Advertise . . . . 65 124 2.54. Section 4.3 - Routes v. Destinations - Withdraw . . . . . 66 125 2.55. Section 4.3 - Description of AS_PATH length . . . . . . . 68 126 2.56. Section 6 - BGP Error Handling . . . . . . . . . . . . . 69 127 2.57. Section 6.2 - Hold timer as Zero . . . . . . . . . . . . 71 128 2.58. Deprecation of ATOMIC_AGGREGATE . . . . . . . . . . . . . 72 129 2.59. Section 4.3 - Move text . . . . . . . . . . . . . . . . . 80 130 2.60. Section 4.3 - Path Attributes . . . . . . . . . . . . . . 81 131 2.61. Next Hop for Redistributed Routes . . . . . . . . . . . . 82 132 2.62. Deprecate BGP Authentication Optional Parameter from 133 RFC1771 . . . . . . . . . . . . . . . . . . . . . . . . . 84 134 2.63. Clarify MED Removal Text . . . . . . . . . . . . . . . . 88 135 2.64. MED for Originated Routes . . . . . . . . . . . . . . . . 93 136 2.65. Rules for Aggregating with MED and NEXT_HOP . . . . . . . 94 137 2.66. Complex AS Path Aggregating . . . . . . . . . . . . . . . 95 138 2.67. Counting AS_SET/AS_CONFED_* . . . . . . . . . . . . . . . 97 139 2.68. Outbound Loop Detection . . . . . . . . . . . . . . . . . 98 140 2.69. Appendix A - Other Documents . . . . . . . . . . . . . . 99 141 3. The Issues from -18 to -19 . . . . . . . . . . . . . . . . . 100 142 3.1. Reference to RFC 1772 . . . . . . . . . . . . . . . . . . 100 143 3.2. MUST/SHOULD Capitalization . . . . . . . . . . . . . . . 100 144 3.3. Fix Update Error Subcode 7 -- accidently removed . . . . 101 145 3.4. Section 5.1.4 - Editorial Comment . . . . . . . . . . . . 101 146 3.5. Section 9.1 - Change "all peers" to "peers" . . . . . . . 102 147 3.6. AS Loop Detection & Implicit Withdraws . . . . . . . . . 102 148 3.7. Standardize FSM Timer Descriptions . . . . . . . . . . . 103 149 3.8. FSM MIB enumerations . . . . . . . . . . . . . . . . . . 104 150 3.9. Make "delete routes" language consistent . . . . . . . . 104 151 3.10. Correct OpenSent and OpenConfirm delete wording . . . . . 105 152 3.11. Incorrect next state when the delay open timer expires . 105 153 3.12. Entering OpenConfirm / Adding "Stop OpenDelay" action . . 106 154 3.13. FSM Missing Next States . . . . . . . . . . . . . . . . . 110 155 3.13.1. FSM Missing Next States - Event 15 or 16 (Connect 156 State) . . . . . . . . . . . . . . . . . . . . . . . 111 157 3.13.2. FSM Missing Next States - Event 14 (Connect State) . 112 158 3.13.3. FSM Missing Next States - Event 15 or 16 (Active 159 State) . . . . . . . . . . . . . . . . . . . . . . . 114 160 3.13.4. FSM Missing Next States - Event 13-17 (TCP 161 Connection) . . . . . . . . . . . . . . . . . . . . 114 162 3.13.5. FSM Missing Next States - Event 17 (Connect State) . 116 163 3.13.6. FSM Missing Next States - Event 18 (Open Confirm) . 118 164 3.14. FSM - Peer Oscillation Damping . . . . . . . . . . . . . 120 165 3.15. FSM - Consistent FSM Event Names . . . . . . . . . . . . 121 166 3.16. Many Editorial Comments . . . . . . . . . . . . . . . . . 123 167 3.17. Section 3, Page 8, Paragraph 3 - Obsolete? . . . . . . . 127 168 3.18. MED Removal Text . . . . . . . . . . . . . . . . . . . . 130 169 3.19. Security Considerations . . . . . . . . . . . . . . . . . 133 170 3.20. Peer Oscillation Damping . . . . . . . . . . . . . . . . 133 171 3.21. Session Attributes - IdleHold Timer . . . . . . . . . . . 134 172 3.22. Specify New Attributes (Accept Connections/Peer 173 Oscillation Damping) . . . . . . . . . . . . . . . . . . 135 174 3.23. Event1/Event2 Clean Up . . . . . . . . . . . . . . . . . 136 175 3.24. Events 3, 5, 6 & 7 Give Examples . . . . . . . . . . . . 137 176 3.25. Event 4 & 5 Session Initiation Text . . . . . . . . . . . 138 177 3.26. Event 4 & 5 - bgp_stop_flap option . . . . . . . . . . . 139 178 3.27. Event 5 Clarification . . . . . . . . . . . . . . . . . . 141 179 3.28. Timer Events Definition - Make Consistent . . . . . . . . 141 180 3.29. Event 8 - Clean Up . . . . . . . . . . . . . . . . . . . 142 181 3.30. Hold Timer - Split? . . . . . . . . . . . . . . . . . . . 142 182 3.31. OpenDelay Timer Definition . . . . . . . . . . . . . . . 143 183 3.32. Definition of TCP Connection Accept (Event 13) . . . . . 143 184 3.33. Event 13 & 14 - Valid Addresses & Ports . . . . . . . . . 144 185 3.34. Event 17 - TCP Connection Fails to TCP Connection 186 Termination . . . . . . . . . . . . . . . . . . . . . . . 144 187 3.35. Making Definition Style Consistent . . . . . . . . . . . 145 188 3.36. Event 19 - Definition Cleanup . . . . . . . . . . . . . . 147 189 3.37. Event 22 - Cleanup . . . . . . . . . . . . . . . . . . . 148 190 3.38. FSM Description - ConnectRetry Count . . . . . . . . . . 149 191 3.39. Handling Event 7 (Auto Stop) to Idle State processing . . 149 192 3.40. Clearing the Connection Retry Timer . . . . . . . . . . . 150 193 3.41. Handling of Event 14 in the Connect State . . . . . . . . 151 194 3.42. Handling events 20, 21 in the Connect State and Active 195 State . . . . . . . . . . . . . . . . . . . . . . . . . . 152 196 3.43. Handling the default events in the Connect state . . . . 155 197 3.44. Handling Event 23 in Connect and OpenSent . . . . . . . . 156 198 3.45. Event 17 in the Connect state . . . . . . . . . . . . . . 158 199 3.46. Handling of Event 17 in Active state . . . . . . . . . . 161 200 3.47. Handling of Event 19 in Active state . . . . . . . . . . 161 201 3.48. Handling of Event 2 in Active state . . . . . . . . . . . 162 202 3.49. Default Event handling in Active state . . . . . . . . . 163 203 3.50. Clearing Hold timer in OpenSent, OpenConfirm and 204 Established State . . . . . . . . . . . . . . . . . . . . 164 205 3.51. Clearing Keepalive timer in OpenConfirm and 206 Established State . . . . . . . . . . . . . . . . . . . . 164 207 3.52. Handling Event 18 in the OpenSent state (Keepalive 208 Timer) . . . . . . . . . . . . . . . . . . . . . . . . . 165 209 3.53. Established State MIB . . . . . . . . . . . . . . . . . . 167 210 3.54. State impact of not supporting Optional Events . . . . . 168 211 3.55. New DelayOpen State . . . . . . . . . . . . . . . . . . . 169 212 3.56. Clarify what is covered in the base document . . . . . . 169 213 4. Security Considerations . . . . . . . . . . . . . . . . . . . 170 214 5. Normative References . . . . . . . . . . . . . . . . . . . . 170 215 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 170 217 1. Introduction 219 This document records the issues discussed and the consensus reached 220 in the Interdomain Routing (IDR) Working Group during its efforts to 221 revise and bring up to date the base specification for the BGP-4 222 protocol as documented in RFC1771. The results of these efforts are 223 encoded in RFC4271. The rational for doing this is simple: 224 Experience has demonstrated that the same issues and questions tend 225 to come up again and again. This memo will document not only the 226 decisions on these issues but also how and why the working group 227 reached those conclusions. We hope that this will help make future 228 discussions more fruitful by providing them with a historical 229 context. 231 This document traces the evolution of the BGP-4 base specification 232 from its incarnation as draft-ietf-idr-bgp4-17.txt through the big 233 revision and update push culminating in draft-ietf-idr-bgp4-19.txt. 234 It is divided into two main sections. The first deals with the 235 issues discussed between -17 and -18, and the second deals with the 236 issues discussed between -18 and -19. 238 N.B. There is no rhyme or reason to the numbering scheme other than 239 unique tags to address the issues. 241 2. The Issues from -17 to -18 243 This section lists the issues discussed on the list from late August 244 to late October 2002. 246 2.1. IDR WG Charter 248 Status: Consensus 249 Change: Yes 250 Summary: New charter adopted. 252 Discussion: 254 A variety of discussions surrounded the new charter. The rough 255 consensus is to accept the new charter that the AD's have proposed, 256 and to push as hard a possible to get the base spec to RFC status so 257 other drafts that are dependent can also move forward. 259 For our information, Alex has provided these approximate time lines: 261 Stage Anticipated delay Comment 262 -------------------------------------------------------------------- 263 AD-review 1-4 weeks The document may go back depending on to the WG 264 for the workload AD-review comments to be addressed; this would 265 introduce additional delay. 267 IETF LC 2 weeks Same as above 269 IESG review & 1-2 weeks depending Same as above telechat on when the 270 IETF LC ends 271 -------------------------------------------------------------------- 273 Note that if the document is sent back to the WG at some stage, 274 required changes may warrant an additional WG Last Call. 276 I can personally commit to a 2-week upper bound for the AD-review 277 period. Bill may have a different timer granularity. 279 The opinions expressed on this were 7 in favor, 4 against. 281 This thread has messages subjects of "BGP spec and IDR WG charter" 282 and "IDR WG charter". 284 2.2. TCP Port 286 Status: Consensus 287 Change: Yes 288 Summary: 290 Change: 291 "BGP uses TCP port 179 for establishing its connections." 293 To: 294 "BGP listens on TCP port 179." 296 Discussion: 298 There has been a discussion on clarifying the wording in Section 2, 299 on which port BGP uses. The original text was: 301 "BGP uses TCP port 179 for establishing its connections." 303 The proposed new text is: 305 "BGP listens on TCP port 179." 307 There seems to be a rough consensus that the new text is better. 309 This thread has a message subject of "Review: Section 2, TCP Port 310 179" 312 2.3. FSM wording for what state BGP accepts connections in 314 Status: Consensus 315 Change: No 316 Summary: No change necessary 318 Discussion: 320 An issue was brought up later in the "Review: Section 2, TCP Port 321 179" thread about the words in the FSM for what state BGP accepts 322 connections in. The consensus is that the existing wording is clear. 324 2.4. BGP Identifier/Router ID 326 Status: Consensus 327 Change: No 328 Summary: No change necessary to base draft. Perhaps in a BCP. 330 Discussion: 332 The "admin dist/gp spec proposal", "Router ID" and "bgp spec 333 proposal" threads discussed the BGP Identifier and how close or not 334 it is to IGP's Router ID. The consensus was that this discussion is 335 better saved for a BCP draft, and that it does not need to be 336 contained in the base spec. 338 2.5. Direct EBGP Peers 340 Status: Consensus Change: No Summary: A recollection that ebgp peers 341 must be direct. No text proposed, no discussion. 343 Discussion: 345 Jonathan recalled something that stated that ebgp peers must be 346 direct. No specific sections were quoted. 348 Yakov responded to this with: 350 Section 5.1.3 talks about both the case where ebgp peers are 1 IP hop 351 away from each other: 353 2) When sending a message to an external peer X, and the peer is one 354 IP hop away from the speaker: 356 as well as the case where they are multiple IP hops away from each 357 other: 359 3) When sending a message to an external peer X, and the peer is 360 multiple IP hops away from the speaker (aka "multi hop EBGP"): 362 And emphasized that multi hop EBGP does exist. 364 This came up in the "bgp draft review" thread. 366 2.6. Disallow Private Addresses 368 Status: Consensus 369 Change: No 370 Summary: No change necessary 372 Discussion: 374 In the thread entitled "bgp draft review": 376 Mentioned explicitly disallowing private addresses. The consensus 377 was that there is no reason to disallow them. Which IP addresses 378 peers use is an operational issue. 380 2.7. Renumber Appendix Sections 382 Status: Consensus 383 Change: Yes 384 Summary: Rename/renumber appendix sections so they do not have the 385 same numbers as sections of the main text. 387 Discussion: 389 In the tread entitled "bgp draft review": 391 This thread brought up renaming sections in the appendix to avoid 392 confusion with sections of the same number in the main text. 394 Yakov responded that he would do so in the next edition. 396 2.8. Jitter Text 398 Status: Consensus 399 Change: Yes 400 Summary: 402 Get rid of section 9.2.1.3 ("Jitter"). Move the text to an 403 Appendix: "BGP Timers" Expand text to indicate that jitter applies 404 to all timers, including ConnectRetry. 406 The text for the appendix is listed at the end of the discussion. 408 Discussion: 410 In the tread entitled "bgp draft review": The thread also proposed: 412 "jitter should be applied to the timers associated with 413 MinASOriginationInterval, Keepalive, and 414 MinRouteAdvertisementInterval" 416 Be changed to: 418 "jitter should be applied to the timers associated with ConnectRetry 419 timer" 421 Yakov agreed with making some changes and suggested that we make sure 422 that jitter is applied to all timers. Specifically, he proposes we 423 get rid of section 9.2.1.3 ("Jitter"), move the text of this section 424 into Appendix "BGP Timers", and expand the text to indicate that 425 jitter applies to ConnectRetry timer as well. 427 Jonathan, the original commenter, agreed with Yakov's suggestion. 429 In a follow-up to this issue, there was a question raised about the 430 values we have specified for timers in the document. Specifically: 432 The ConnectRetry timer is should have a value that is 'sufficiently 433 large to allow TCP initialization. Application of jitter can reduce 434 the this value (by up to 25%). A configuration which the 435 ConnectRetry timer has been pegged at a value close to TCP connection 436 time may cause a connection to be terminated as a result of this 437 jitter. Is this a cause for concern ? 439 The default value suggested for ConnectRetry (120 seconds) is 440 sufficiently large that event with a jitter of 0.75, it will be 441 greater than TCP's connection establishment timer. 443 Is adding a jitter to the ConnectRetry timer a standard practice ? 444 What benefit does this provide ? 446 Curtis responded to this with: 448 The TCP connection establishment timer is 75 seconds (sysctl yield 449 "net.inet.tcp.keepinit: 75000" in BSD-oids). 451 The ConnectRetry determines when to make a second attempt after a 452 prior attempt to connect has failed. It is to avoid a rapid 453 succession of retries on immediate failures (for example "Connection 454 refused" if the peer was in the middle of a reboot, Network 455 Unreachable if you can't get there from here, etc) but also covers 456 the case where the TCP SYN goes off and is never heard from again. 458 And Jonathan replied with this information about current practice: 460 It seems to me that if you bring up all bgp peers at once it may lead 461 to load spikes on the network. Cisco seems to wait 27.5 +/- 2.5 462 seconds for IBGP, and 40 +/- 5 seconds for EBGP--20 sec. from config 463 time to the "open active, delay" jittered delay assignment plus the 464 jittered delay (5 to 10 sec. for IBGP, and 15 to 25 sec. for EBGP). 465 This would also apply for "no neighbor x.x.x.x shutdown". Their 466 value of ConnectRetry is 60sec. though, not sure how this value is 467 used (based on above). Maybe some Cisco folks can chime in on this 468 one??? 470 I did not check Juniper. 472 Also, interestingly, they do not apply jitter to the other timers (as 473 far as I can tell), but I don't see a problem with this. 475 Another timer that they use that is not mentioned in the draft/rfc is 476 the next hop resolution timer which is 30 seconds. Although it would 477 be nice to have this in the spec, I will concede that it is out of 478 scope and/or implementation dependent. 480 So the question that arises from this followup, is how does this 481 question affect the text of the appendix on jitter? 483 Curtis replied that we need to only state that jitter should be 484 applied to all timers. Whether a vendor does so or not is a minor 485 deficiency and does not bear on interoperability. Therefore, 486 specifying exact details are not necessary. 488 After Jonathan's response Curtis and Jonathan agreed that jitter 489 should be added to all timers and that we should state so in the 490 text. 492 Yakov proposed the following text for the appendix to discuss jitter: 494 I'd like to propose the following text for "BGP Timers" section: 496 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 497 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 498 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 499 9.2.1.1). 501 The suggested value for the ConnectRetry timer is 120 seconds. 503 The suggested value for the Hold Time is 90 seconds. 505 The suggested value for the KeepAlive timer is 1/3 of the Hold Time. 507 The suggested value for the MinASOriginationInterval is 15 seconds. 509 The suggested value for the MinRouteAdvertisementInterval is 30 510 seconds. 512 An implementation of BGP MUST allow the Hold Time timer to be 513 configurable, and MAY allow the other timers to be configurable. 515 To minimize the likelihood that the distribution of BGP messages by a 516 given BGP speaker will contain peaks, jitter should be applied to the 517 timers associated with MinASOriginationInterval, Keepalive, 518 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 519 shall apply the same jitter to each of these quantities regardless of 520 the destinations to which the updates are being sent; that is, jitter 521 will not be applied on a "per peer" basis. 523 The amount of jitter to be introduced shall be determined by 524 multiplying the base value of the appropriate timer by a random 525 factor which is uniformly distributed in the range from 0.75 to 1.0. 527 Jeff & Ben agreed with this. 529 Justin suggested that we move the range from 0.75 to 1.25 to ensure 530 that the average is around the configured value. Yakov agreed with 531 Justin's changes. Jonathan disagreed, arguing that it was out-of- 532 scope for the task of clarifying the text only. Justin agreed and 533 withdrew his comment. 535 Curtis liked the general text, but suggested these modifications: 537 minor improvement (not really an objection) -- s/suggested value/ 538 suggested default value/g 540 Also 542 s/shall apply the same jitter/may apply the same jitter/ (to each of 543 these quantities regardless of ...). 545 s/jitter will not be applied/jitter need not be configured/ (on a 546 "per peer" basis). 548 He stated that in Avici's implementation they allow a lot of 549 granularity in timer settings, so this reflects current practice. 551 Curtis also suggested changing the last paragraph: 553 The suggested default amount of jitter shall be determined by 554 multiplying the base value of the appropriate timer by a random 555 factor which is uniformly distributed in the range from 0.75 to 1.0. 556 A new random value should be picked each time the timer is set. The 557 range of the jitter random value MAY be configurable. 559 This would make it clear that it is possible to have this timer as 560 configurable and still be within spec. 562 Other comments on Yakov's text pointed out that IOS uses 5 seconds as 563 the default IBGP MinRouteAdvertisementInterval. 565 Tom pointed out that there seems to be a discrepancy between this 566 text and the FSM: The FSM has an OpenDelay timer. And the FSM 567 suggests a HoldTimer of 4 minutes. 569 In following up on this issue, Yakov stated: 571 Here is the final text for the BGP Timers section: 573 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 574 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 575 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 576 9.2.1.1). 578 The suggested default value for the ConnectRetry timer is 120 579 seconds. 581 The suggested default value for the Hold Time is 90 seconds. 583 The suggested default value for the KeepAlive timer is 1/3 of the 584 Hold Time. 586 The suggested default value for the MinASOriginationInterval is 15 587 seconds. 589 The suggested default value for the MinRouteAdvertisementInterval is 590 30 seconds. 592 An implementation of BGP MUST allow the Hold Time timer to be 593 configurable, and MAY allow the other timers to be configurable. 595 To minimize the likelihood that the distribution of BGP messages by a 596 given BGP speaker will contain peaks, jitter should be applied to the 597 timers associated with MinASOriginationInterval, Keepalive, 598 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 599 may apply the same jitter to each of these quantities regardless of 600 the destinations to which the updates are being sent; that is, jitter 601 need not be configured on a "per peer" basis. 603 The suggested default amount of jitter shall be determined by 604 multiplying the base value of the appropriate timer by a random 605 factor which is uniformly distributed in the range from 0.75 to 1.0. 606 A new random value should be picked each time the timer is set. The 607 range of the jitter random value MAY be configurable. 609 With this in mind, I would suggest we mark this issue as closed. 611 Jonathan suggested adding "per peer" to the text, Yakov responded 612 with this text: 614 An implementation of BGP MUST allow the Hold Time timer to be 615 configurable on a per peer basis, and MAY allow the other timers to 616 be configurable. 618 This proposal met with general agreement. This issue is at 619 consensus. 621 2.9. Reference to RFC904 - EGP Protocol 623 Status: Consensus 624 Change: Yes 625 Summary: Add a reference to RFC904 627 Discussion: 629 The "Review Comment: Origin Attribute pg 14" thread suggested adding 630 a reference to RFC904(?), to refer to the EGP protocol. There was no 631 discussion. 633 Yakov agreed to this, and Jonathan seconded it. 635 2.10. Extending AS_PATH Attribute 637 Status: Consensus 638 Change: Yes 639 Summary: Add this to 9.2: 641 If due to the limits on the maximum size of an UPDATE message (see 642 Section 4) a single route doesn't fit into the message, the BGP 643 speaker MUST not advertise the route to its peers and may choose to 644 log an error locally. 646 Discussion: 648 The "Extending AS_PATH attribute length en route" thread brought up 649 the issue of what action should we specify when we receive a route 650 with an AS_PATH that exceeds the defined maximum length. There was 651 some discussion, and it was suggested that, after logging the error, 652 the route not be propagated. 654 Yakov stated that: 656 The real issue here is how to handle the case when a route (a single 657 address prefix + path attributes) doesn't fit into 4K bytes (as the 658 max BGP message size is 4 K). To address this issue I would suggest 659 to add the following to 9.2: 661 After some discussion, Yakov's proposed text's last sentence was 662 dropped and we arrived at: 664 If due to the limits on the maximum size of an UPDATE message (see 665 Section 4) a single route doesn't fit into the message, the BGP 666 speaker may choose not to advertise the route to its peers. 668 In response to Andrew's clarification question to the list, Curtis 669 responded: 671 Wording would be more like: 673 If the attributes for a specific prefix becomes too large to fit the 674 prefix into the maximum sized BGP UPDATE message, the prefix should 675 not be advertised further. Truncation or omission of attributes 676 should not occur unless policies for such modifications are 677 specifically configured. Such policies may contribute to the 678 formation of route loops and are not within the scope of this 679 protocol specification. 681 After some additional discussion, it was decided that we add "and may 682 choose to log an error locally." to the end of Yakov's text. 684 Also, we agreed to change "may choose not to advertise..." to "MUST 685 NOT advertise...". 687 So the text on the table right now is: 689 If due to the limits on the maximum size of an UPDATE message (see 690 Section 4) a single route doesn't fit into the message, the BGP 691 speaker MUST not advertise the route to its peers and may choose to 692 log an error locally. 694 This met with one agreement and no disagreements. We have a 695 consensus. 697 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 699 Status: Consensus 700 Change: Yes 701 Summary: Add this text: 703 The local speaker SHALL then install that route in the Loc-RIB, 704 replacing any route to the same destination that is currently being 705 held in the Loc-RIB. When the new BGP route is installed in the 706 Rout- ing Table, care must be taken to ensure that existing routes to 707 the same destination that are now considered invalid are removed from 708 the Routing Table. Whether or not the new BGP route replaces an 709 existing non-BGP route in the Routing Table depends on the policy 710 configured on the BGP speaker. 712 Discussion: 714 The "Proxy: comments on section 9.1.3" thread brought up some lack of 715 clarity in the section discussing the rules for which routes get 716 propagated from the Loc-RIB into the Adj-RIB-Out. These discussions 717 resulted in a number of suggestions for new text. 719 The first new text was proposed to clarify the issue that the thread 720 first brought up: 722 I agree that this could use some clarification. How about adding to 723 b) in section 9.1: 725 The Loc-RIB must contain only one route per destination; further, it 726 must include all routes that the BGP speaker is using. 728 changing c) in section 9.1.2 to: 730 c) is selected as a result of the Phase 2 tie breaking rules 731 specified in 9.1.2.2, or 733 and adding 735 d) when routing protocols other than BGP are in use, is determined by 736 some other local means to be the route that will actually be used to 737 reach a particular destination. 739 This text was never discussed or a consensus formed on putting it in 740 the document. 742 This modification to 9.1.2 was also proposed to address the same 743 concern: 745 How about changing the paragraph after c) in 9.1.2 to: 747 The local speaker SHALL then install that route in the Loc-RIB, 748 replacing any route to the same destination that is currently being 749 held in the Loc-RIB. This route SHALL then also be installed in the 750 BGP speakers forwarding table. 752 There was one response in the negative to this change, arguing that 753 is is not necessary. 755 Yakov replied to this that: 757 Wrt "adding to b) in section 9.1", the second part (after ";") is 758 redundant as this point is already stated in 3.2. Wrt the first 759 point about Loc-RIB containing just one route per destination, I 760 would suggest to add it to section 3.2, where Loc-RIB is first 761 introduced, rather than adding it to 9.1. 763 Wrt "changing c)... and adding...", I have no objections to add/ 764 modify the text, as suggested above. 766 I am not sure though that changing the paragraph after c) in 9.1.2 is 767 really necessary though, so I would prefer to keep it as is. 769 The "issue 11" thread this was being discussed in then digressed to 770 the topic, now covered in issue 11.3. 772 Ben re-addressed the original issue with this input: 774 I have somewhat of an issue with the paragraph after item c section 775 9.1.2 as discussed. 777 which is => 779 "The local speaker SHALL then install that route in the Loc-RIB, 780 replacing any route to the same destination that is currently being 781 held in the Loc-RIB. If the new BGP route is installed in the 782 Routing Table (as a result of the local policy decision), care must 783 be taken to ensure that invalid BGP routes to the same destination 784 are removed from the Routing Table. Whether or not the new route 785 replaces an already existing non-BGP route in the routing table 786 depends on the policy configured on the BGP speaker." 788 Can we assume that its OK to have a route present in the Loc-RIB and 789 possibly in the adj-RIB-Out but not in the Routing table due to some 790 policy. Won't we violate rule number 1? Only advertise what you 791 use. 793 As conversely implied in this sentence => 795 "If the new BGP route is installed in the Routing Table (as a result 796 of the local policy decision), care must be taken to ensure that 797 invalid BGP routes to the same destination are removed from the 798 Routing Table" 800 I would rephrase the paragraph as follows => 802 "The local speaker SHALL then install that route in the Loc-RIB, 803 replacing any route to the same destination that is currently being 804 held in the Loc-RIB. When the new BGP route is installed in the 805 Routing Table, care must be taken to ensure that existing routes to 806 the same destination that are now considered invalid are removed from 807 the Routing Table. Whether or not the new BGP route replaces an 808 existing non-BGP route in the routing table depends on the policy 809 configured on the BGP speaker." 811 Jeff replied: 813 With the exception that Routing Table should be capitalized 814 throughout, I'd suggest we take this as consensus. 816 Yakov agreed. We are at consensus. 818 2.11.1. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3 820 Status: Consensus 821 Change: Yes 822 Summary: The text below will be added to the -18 version. 824 Discussion: 826 In further discussions around this issue, this text was also 827 proposed: 829 How about adding to section 9.1.3, at the end: 831 Any local-policy which results in reachability being added to an Adj- 832 RIB-Out without also being added to the local BGP speaker's 833 forwarding table is beyond the scope of this document. 835 This suggestion received one response that agreed to this change. 837 This text will be added to the -18 version, and since there were no 838 objections, this issue has been moved to consensus. 840 2.11.2. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2 842 Status: Consensus 843 Change: Yes 844 Summary: Add this text: 846 In the context of this document we assume that a BGP speaker 847 advertises to its peers only those routes that it itself uses (in 848 this context a BGP speaker is said to "use" a BGP route if it is the 849 most preferred BGP route and is used in forwarding). All other cases 850 are outside the scope of this document. 852 Discussion: 854 Additionally this thread produced this section of new text, in 855 section 2: 857 859 "one must focus on the rule that a BGP speaker advertises to its 860 peers (other BGP speakers which it communicates with) in neighboring 861 ASs only those routes that it itself uses." 863 Should be changed to 865 867 "one must focus on the rule that a BGP speaker advertises to its 868 peers (other BGP speakers which it communicates with) in neighboring 869 ASs only routes whose NLRIs are locally reachable." 871 873 "one must focus on the rule that a BGP speaker advertises to its 874 peers (other BGP speakers which it communicates with) in neighboring 875 ASs only routes which are locally reachable. Local reachability can 876 be achieved by having any protocol route to the given destination in 877 the routing table." 879 There were a lot of emails exchanged on this topic with a variety of 880 texts proposed (see early in the "Active Route" thread). This issue 881 reopened with Jonathan, who brought up the issue originally, stating 882 that: 884 The issue I raised, and would like to be [re-]considered is with: 886 "one must focus on the rule that a BGP speaker advertises to its 887 peers (other BGP speakers which it communicates with) in neighboring 888 ASs only those routes that it itself uses." 890 Curtis replied that: 892 That is called route origination and it is allowed by: 894 9.4 Originating BGP routes 896 A BGP speaker may originate BGP routes by injecting routing 897 information acquired by some other means (e.g. via an IGP) into BGP. 898 [...] The decision whether to distribute non-BGP acquired routes 899 within an AS via BGP or not depends on the environment within the AS 900 (e.g. type of IGP) and should be controlled via configuration. 902 Advice on what to put in the AS_PATH and NEXT_HOP is in the document. 904 He continued with: 906 I don't think there was ever consensus on what to do with the 907 statement "a BGP speaker advertises to its peers (other BGP speakers 908 which it communicates with) in neighboring ASs only those routes that 909 it itself uses". Some reasonable choices are: 911 1. Omit it (the implied consensus of the rewrite of the paragraph in 912 32.2). 914 2. Leave it as is and put it in another paragraph to separate it 915 from the destination based routing statement. 917 3. Clean up the wording and put it in another paragraph to separate 918 it from the destination based routing statement. 920 The separate paragraph for 2 would be the exact sentence we now have. 922 A BGP speaker advertises to its peers (other BGP speakers which it 923 communicates with) in neighboring ASs only those routes that it 924 itself uses. 926 In possibility 3 we (try to) clear up the ambiguity about the meaning 927 of the word "use" in this sentence. 929 A BGP speaker advertises to its peers (other BGP speakers which it 930 communicates with) in neighboring ASs only those routes that it 931 itself uses. In this context a BGP speaker is said to "use" a BGP 932 route if it is the most preferred BGP route and is either directly 933 used in forwarding or in a specifically configured case where the BGP 934 route would be forwarded internally but IGP forwarding information is 935 used. The latter case reflects a usage in which the IGP is used for 936 forwarding but BGP is originated to IBGP to carry attributes that 937 cannot be carried by the IGP (for example, BGP communities [N]). 938 Other special cases such as virtual routers and multiple instances of 939 BGP on a single router are beyond the scope of this document but for 940 each of these the statement "a BGP speaker advertises to its peers 941 (other BGP speakers which it communicates with) in neighboring ASs 942 only those routes that it itself uses" can (and should in the 943 definition of the extension) be made true with an appropriate 944 definition of the word "use". 946 Unless someone volunteers better wording this may be a good starting 947 point. I thing the last sentence borders on ridiculous in a protocol 948 spec but may be necessary to address specific objections raised on 949 this mailing list. If we want to elaborate on the meaning of the 950 word "use" and address the objections this is what we end up with. 952 Of course looking at what we ended up with, I'd also go along with 953 the other two options (leave it out or put the one sentence in a 954 separate paragraph as is). 956 After some additional discussion (in the "issue 11.2" thread), we 957 have come to a consensus on this text: 959 In the context of this document we assume that a BGP speaker 960 advertises to its peers only those routes that it itself uses (in 961 this context a BGP speaker is said to "use" a BGP route if it is the 962 most preferred BGP route and is used in forwarding). All other cases 963 are outside the scope of this document. 965 This issue is at consensus. 967 2.11.3. Documenting IBGP Multipath 969 Status: Consensus 970 Change: Yes 971 Summary: The documenting of IBGP Multipath is left to another 972 Internet Draft. The consensus is that it should not be in the base 973 spec. 975 Discussion: 977 This thread began in the "issue 11" discussion. In it it was 978 proposed that: 980 There is support in some router vendors to allow more than one BGP 981 route to be installed, for the purpose for load balancing. Given 982 that this is a current practice, and seems to be a useful feature as 983 well, should we insist that only one route be installed in the Loc- 984 RIB ? 986 I would like to suggest that all sections which use MUST in the 987 context of only one route in Loc-RIB be relaxed a little to a SHOULD, 988 and a section added that states that it is possible for a n 989 implementation to add more than one route to the Loc-RIB for the 990 purposes of load balancing. 992 While it will be useful to describe how this situation is the 993 handler, it is perhaps sufficient to even state that handling of this 994 situation is outside the scope of this RFC. 996 I am including some proposed text for this purpose: 998 For the part: 1000 > The Loc-RIB must contain only one route per destination; 1002 consider instead, 1004 % The Loc-RIB SHOULD contain only one route per destination. % An 1005 implementation may choose to install multiple routes to % a 1006 destination (for the purposes of load balancing). The % handling of 1007 such a configuration, however, is outside the % scope of this RFC. 1009 Perhaps, this can be in section 3.2 instead. 1011 After much discussion back and forth, it was agreed that documenting 1012 IBGP Multipath behavior is a good thing. However, it is something 1013 that belongs in another draft. 1015 Alex opened this issue up again. There were a flurry of responses, 1016 most all of them agreeing with the original consensus that we should 1017 document this feature in a different draft, since it doesn't affect 1018 the core interoperability requirements, and we want to advance the 1019 spec in a timely manner. 1021 Alex persisted in his assertion that this belongs in the base 1022 specification. Right now, the issue is still open. 1024 This discussion later expanded in scope to include all BGP multipath. 1026 Curtis laid out a good description of the various flavors of 1027 multipath: 1029 In addition to IGP multihop, there are two cases of BGP multipath. 1031 In IGP multihop there is one BGP advertisement but to ways to reach 1032 th BGP NEXT_HOP via the IGP. 1034 In one case of BGP multihop, two (or more) IBGP routers peering with 1035 the same external AS have equal routes to a destination and are an 1036 equal cost away from a third router. BGP multihop is applicable to 1037 that third router. Without BGP multihop, BGP would normally pick the 1038 BGP NEXT_HOP of the advertisement from only one of those IBGP peers 1039 (using BGP Identifier) and use that. The IGP lookup would yield one 1040 next hop. With BGP multihop, BGP uses the BGP NEXT_HOP of both 1041 advertisements. Each BGP NEXT_HOP has a different IGP next hop (one 1042 or more IGP next hop). 1044 The second case is where all of the candidates routes for BGP 1045 multipath are external. Seldom does IGP multipath come into play for 1046 EBGP (odd tunneled EBGP multihop cases maybe). Typically the load is 1047 split among two (or more) routers in the same AS. 1049 If in EBGP multipath you split among routers in difference AS, an 1050 aggregate should be formed. This is still prior to the IGP cost rule 1051 in the route selection. 1053 Normally one would not combine IBGP and EBGP in multihop given that 1054 the decision point for multihop is after "d" in 9.1.2.2. If the 1055 multihop decision was prior to "d", then two routers each with an 1056 external peering would forward some of the traffic to each other and 1057 for some src/dst pairs, they'd form a loop. [So don't do that!] 1059 This is getting to be a lot to add to the base spec. I hope we've 1060 convinced you that we should put it in another document. 1062 Curtis later added specific text, that could serve as a start for the 1063 new document (or added to the base spec if the consensus ended up 1064 going the other way): 1066 BGP specifies how to select the single best route. OSPF specifically 1067 defines procedures for handling equal cost multipath (ECMP) [cite 1068 OSPF]. The same technique has been applied to ISIS. A similar 1069 technique has been used with BGP. Variations exist but the decision 1070 to support BGP multipath, the specific variation of BGP multipath, or 1071 not to support it, does not affect interoperability. 1073 A naive implementations of ECMP can cause severe performance 1074 degradation for TCP flows. To avoid this, implementations of BGP 1075 multipath SHOULD maintain packet ordering within microflows as 1076 described in [cite rfc2991, rfc2992]. 1078 BGP multipath, if implemented, SHOULD be disabled by default. 1080 In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there 1081 are two variations of BGP multipath described here. A BGP 1082 implementation may offer both, either one, or neither variation of 1083 BGP multipath. Other variations of BGP multipath may exist, but no 1084 guarantees can be made in this protocol specification of their 1085 properties or impact on interoperability. 1087 Where IGP multipath is used, there is an interaction with BGP learned 1088 routes. The lookup of a BGP NEXT_HOP in the IGP can result in the 1089 selection of an IGP multipath entry. This is not a variation of BGP 1090 multipath. When this occurs, one BGP route is selected as the best 1091 but there is more than one way to reach the BGP NEXT_HOP via the IGP. 1093 In one variation of BGP multipath, a set of more than one IBGP 1094 routers peering with the same external AS have equal routes to a 1095 destination and are an equal IGP cost away from a second set of one 1096 or more routers. BGP multipath is applicable to the latter set of 1097 routers. Without BGP multipath, BGP would pick the BGP NEXT_HOP of 1098 the advertisement from only one of those IBGP peers (using BGP 1099 Identifier) and use only that BGP route. With BGP multipath, BGP 1100 uses the BGP NEXT_HOP of more than one of these equal cost 1101 advertisements, yielding more than one BGP NEXT_HOP. Each BGP 1102 NEXT_HOP has a different IGP next hop (one or more IGP next hop if 1103 IGP multipath is in use). 1105 The second case is where all of the candidates routes for BGP 1106 multipath are external and learned by a single BGP peer. Without BGP 1107 multipath this peer would select only one of the BGP routes and 1108 obtain only one BGP NEXT_HOP. With BGP multipath, more than one 1109 equal cost route is selected yielding more than one BGP NEXT_HOP. 1110 Seldom does IGP multipath come into play when looking up an EBGP 1111 NEXT_HOP but could in principle be applicable. 1113 If in EBGP multipath traffic is split among routers in difference AS, 1114 an aggregate SHOULD be formed so as to propagate a route with an 1115 accurate AS_PATH. If the resulting aggregate is not more specific 1116 than the components, the AS_SET SHOULD NOT be dropped. 1118 The decision point for multipath is after step "d" in Section 9.1.2.2 1119 (prefer externally learned routes). IBGP learned and EBGP learned 1120 routes MUST NOT be combined in multipath. If the multipath decision 1121 is prior to "d", then two routers each with an external peering would 1122 form a routing loop. 1124 The decision point for multipath is generally after step "e" in 1125 Section 9.1.2.2. Some relaxation of the "equal cost" rule (also 1126 applicable to IGP multipath) is possible. In addition to the equal 1127 cost BGP NEXT_HOPS available at BGP route selection, if the IGP next 1128 hop for other BGP NEXT_HOPs are of lower cost, then those may be used 1129 as well. This relaxation of the step "e" is possible but is not 1130 widely implemented (and may not be implemented at all). 1132 The consensus of the majority of the IDR WG is to keep this in a 1133 separate draft and out of the base spec. 1135 2.12. TCP Behavior Wording 1137 Status: Consensus 1138 Change: No 1139 Summary: In issue 19 we decided to remove this section entirely. As 1140 a result the previous consensus on this issue (no change) is needed 1141 moot. 1143 Discussion: The subject-less "your mail" thread discussed a wording 1144 clarification from: 1146 "An implementation that would "hang" the routing information process 1147 while trying to read from a peer could set up a message buffer (4096 1148 bytes) per peer and fill it with data as available until a complete 1149 message has been received. " 1151 To something that is more TCP-correct, such as: 1153 "An implementation that would "hang" the routing information process 1154 while trying to received from a peer could set up a message buffer 1155 (4096 bytes) per peer and fill it with data as available until a 1156 complete message has been received. " 1158 (only change: "read" to "received" This was one of a couple of 1159 suggested changes.) 1161 This suggestion was quite contentious, and although there were a 1162 variety of alternate texts proposed, the only consensus was that this 1163 was a very minor issue, and probably not worth changing. 1165 In issue 19 we decided to remove this section entirely. 1167 2.13. Next Hop for Originated Route 1169 Status: Consensus 1170 Change: No 1171 Summary: No responses, assumed consensus to keep things the same. 1173 Discussion: 1175 There was a one-message thread entitled "next hop for originated 1176 route". This message received no response, so the assumption is that 1177 there is a consensus to keep things as they are. 1179 For related discussion see issue 61. 1181 2.14. NEXT_HOP to Internal Peer 1183 Status: Consensus 1184 Change: No 1185 Summary: Closed in favor of issue 61. 1187 Discussion: 1189 The thread entitled "NEXT_HOP to internal peer" starts with this 1190 question: 1192 When sending a locally originated route to an internal peer, what 1193 should NEXT_HOP be set to? 1195 One response suggested that we add a line stating that the NEXT_HOP 1196 address originates from the IGP. 1198 Since this issue and issue 61 are basically the same, except 61 1199 proposes text, we'll close this issue in favor of 61. 1201 2.15. Grammar Fix 1203 Status: Consensus 1204 Change: Yes 1205 Summary: Change: "The Prefix field contains IP address prefixes ..." 1206 To: "contains an IP address prefix ..." 1208 Discussion: The thread entitled "Review comment: bottom of page 16" 1209 corrects a grammar mistake by suggesting we change: 1211 "The Prefix field contains IP address prefixes ..." 1213 to: 1215 "contains an IP address prefix ..." 1217 Yakov responded that this will be fixed in -18. 1219 The consensus seems to be to correct this, and go with the new text. 1221 2.16. Need ToC, Glossary and Index 1223 Status: Consensus 1224 Change: Yes 1225 Summary: Need to add a Table of Contents (ToC), Glossary and Index to 1226 the draft. Will be added in draft -18. 1228 Discussion: 1230 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests: 1232 1. Document needs, Table of Contents, Glossary, and Index 1234 2. Paths, Routes, and Prefixes need to be defined in the spec early 1235 on (like in a glossary), so it is obvious what is implied. 1237 Yakov responded that draft -18 will have a ToC and definition of 1238 commonly used terms. 1240 2.17. Add References to other RFC-status BGP docs to base spec 1242 Status: Consensus 1243 Change: Yes 1244 Summary: Add references to other RFC-status BGP docs to the base 1245 spec. 1247 Discussion: 1249 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes 1250 titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to 1251 suggest: 1253 3. All BGP Extensions described in other documents that made it to 1254 RFC status should be at least referenced in the Reference section 1255 P.64. This is justifiable since it's the core BGP standard spec. 1257 Yakov responded that this will be added to the -18 review. 1259 Jonathan agreed. 1261 2.18. IP Layer Fragmentation 1263 Status: Consensus 1264 Change: No 1265 Summary: No need to mention IP Layer Fragmentation in the BGP 1266 specification, since this is taken care of at the TCP level. 1268 Discussion: 1270 1. P.6 section 4. Message Formats, its possible for the source BGP 1271 peer IP layer to fragment a message such that the receiving BGP peer 1272 socket layer would have to reassemble it. Need to mention this, 1273 since BGP implementations are required to do this. 1275 The response to this was that, while true, reassembly is something 1276 that is inherent in the TCP layer that BGP rides over. Therefore, 1277 this is something that is in the TCP spec, and needn't be repeated in 1278 the BGP spec. This comment was reaffirmed. There seems to be 1279 consensus that this isn't something that needs to be in the BGP spec. 1281 2.19. Appendix Section 6.2: Processing Messages on a Stream Protocol 1283 Status: Consensus 1284 Change: Yes 1285 Summary: Remove the section entirely, as this is something that does 1286 not belong in the base spec. 1288 Discussion: 1290 This first came up in response to Issue 17: 1292 There was one comment suggesting that section 6.2 (Processing 1293 Messages on a Stream Protocol" mentioned this. 1295 The original reviewer responded that the out-of-scope comment was 1296 out-of-place and referred the responder to section 6.2 (appendix 6) 1298 The original reviewer stated that he is happy with just adding a 1299 reference to section 6.2 in appendix 6 and leaving it at that. 1301 Curtis suggested we just add a reference to Stevens in appendix 6. 1302 6.2 and be done with it. Specifically: 1304 6.2 Processing Messages on a Stream Protocol 1306 BGP uses TCP as a transport mechanism. If you are unsure as to how 1307 to handle asynchronous reads and writes on TCP sockets please refer 1308 to Unix Network Programming [RWStevens] or other introductory text 1309 for programming techniques for the operating system and TCP 1310 implementation that you are using. 1312 There were further suggestions to remove the section entirely as out- 1313 of-scope. At least 3 people agreed with this. 1315 Alex responded that he sees no reason to remove it, but wouldn't have 1316 a problem if the WG decides to do so. 1318 There seems to be general agreement that this section should be 1319 removed. 1321 N.B. This also affects issue 12. 1323 2.20. Wording fix in Section 4.3 1325 Status: Consensus 1326 Change: Yes 1327 Summary: A small change for clarity in section 4.3 1329 Discussion: 1331 This suggestion grew out of the discussion on Issue 18. 1333 The following change was suggested in section 4.3, second line of the 1334 first paragraph: 1336 s/UPDATE packet/UPDATE message/ 1338 Yakov agreed to this change and updated the draft. 1340 2.21. Authentication Text Update 1342 Status: Consensus 1343 Change: No 1344 Summary: The consensus is that additional references to RFC2385 are 1345 not necessary. 1347 Discussion: 1349 P. 10, "Authentication Data:" section you might want to add this, It 1350 is also possible to use MD5 (RFC2385) at the transport layer to 1351 validate the entire BGP message. 1353 Yakov replied to this: 1355 There is already text that covers this: 1357 "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may 1358 be used in addition to BGP's own authentication mechanisms." 1360 .... 1362 "In addition, BGP supports the ability to authenticate its data 1363 stream by using [RFC2385]." 1365 So, I see no need to add the text proposed above. 1367 Ishi agreed with Yakov. Jonathan disagreed since he thought no one 1368 uses BGP auth. Ishi replied that there are lots of people who do use 1369 it. Jonathan replied with a clarification question: "Who uses *BGP's 1370 own* authentication mechanisms???" Ron Bonica replied that they use 1371 BGP auth. There was some additional discussion over who implements 1372 simple password authentication vs. MD5. 1374 After further discussion, the consensus seems to be that we should 1375 leave the text as it is for the reasons Yakov pointed out. There was 1376 some discussion over opening a new issue to discuss deprecating the 1377 BGP auth mechanism discussed in RFC1771 in favor of the mechanism in 1378 RFC2385. 1380 The issue of Deprecating BGP AUTH is discussed in issue 62. 1382 2.22. Scope of Path Attribute Field 1384 Status: Consensus 1385 Change: Yes 1386 Summary: This is already being covered by text that has been added to 1387 the -18 draft. 1389 Discussion: 1391 P. 12, right after "Path Attributes". The following sentence should 1392 be added to this section to clarify the scope of the Path Attribute 1393 field. "All attributes in the Path Attribute field represent the 1394 characteristics of all the route prefixes defined in the NLRI field 1395 of the message". 1397 Yakov replied to this that: 1399 This will be covered by the following text in 3.1 that will be in the 1400 -18 version (see also issue 54). 1402 Routes are advertised between BGP speakers in UPDATE messages. 1403 Multiple routes that have the same path attributes can be advertised 1404 in a single UPDATE message by including multiple prefixes in the NLRI 1405 field of the UPDATE message. 1407 Therefore there is no need to add the sentence proposed above. 1409 There were no objections to this statement, so this issue has been 1410 moved into consensus. 1412 2.23. Withdrawn and Updated routes in the same UPDATE message 1414 Status: Consensus 1415 Change: No 1416 Summary: For various reasons, not least of which is compatibility 1417 with existing implementations, the decision was made to keep thing 1418 the way they are. 1420 Discussion: 1422 4. P.16, last paragraph in section 4.3 as stated, "An UPDATE message 1423 should not include the same address prefix in the WITHDRAWN ROUTES 1424 and Network Layer Reachability Information fields, however a BGP 1425 speaker MUST be able to process UPDATE messages in this form. A BGP 1426 speaker should treat an UPDATE message of this form as if the 1427 WITHDRAWN ROUTES doesn't contain the address prefix." 1429 This complexity could have been avoided if withdrawn routes and NLRI 1430 prefixes with their attributes were mutually exclusive of each other 1431 and appeared in different update messages. If that was the case, the 1432 priority of which field to process first would have been as simple as 1433 using "first come, first served" message processing approach. 1435 Yakov commented that this would make the case where they are both in 1436 the same message unspecified. 1438 John commented that this is something we don't want to change this 1439 late in the game. Although it was acknowledged that this might be a 1440 good change if we were working from a clean slate. 1442 Ben acceded that this was somewhat wishful thinking on his part. 1444 Curtis's comment seems to coincide with this message, stating: 1446 The existing rules are very clear. 1448 Summarized: 1450 If an UPDATE contains only a withdraw for a prefix, then withdraw 1451 whatever route the peer had previously sent. 1453 If an UPDATE contains the prefix only in the NLRI section, replace 1454 whatever route had previously been advertised by the peer or add a 1455 route if there was no previous route, in both cases adding a route 1456 with the current attributes. 1458 Don't put the same prefix in the same in both the withdraw and NLRI 1459 section of the same update. 1461 If you receive an UPDATE with the same prefix in both the withdraw 1462 and NLRI, ignore the withdraw. [Some older implementations thought 1463 this was a good way to say "delete then add".] 1465 Process UPDATEs from the same peer in the order received. 1467 And goes on to say, that to him, these rules are clear from the 1468 existing text. 1470 Consensus is that while this would be nice, we need to stick with 1471 what we have, and move on. 1473 2.24. Addition or Deletion of Path Attributes 1475 Status: Consensus 1476 Change: Yes 1477 Summary: Add the following to section 3.1: 1479 Changing the attributes of a route is accomplished by advertising a 1480 replacement route. The replacement route carries new (changed) 1481 attributes and has the same NLRI as the original route. 1483 Discussion: 1485 5. P. 20 Its not stated how we delete or modify Path Attributes 1486 associated with NLRI prefixes. 1488 A response to this comment said that this is implicit in the 1489 definition of "route" and the general withdraw/replace behavior and 1490 therefore doesn't need to be repeated. 1492 Ben responded saying that, while there was an assumption, there was 1493 no well defined mechanism, and this leads to ambiguity. 1495 John responded, no need to define everything explicitly, or we'll be 1496 here forever. 1498 Picking this thread up again, Yakov argued: 1500 By *definition* a route is a pair. From that 1501 definition it follows that changing one or more path attributes of a 1502 route means changing a route, which means withdrawing the old route 1503 (route with the old attributes) from service and advertising a new 1504 route (route with the new attributes). Procedures for doing this are 1505 well-defined (see section 3.1), and therefore no new text to cover 1506 this is needed. 1508 Jonathan agreed with this statement, but Ben argued that the text in 1509 section 3 is insufficient the way it is currently written. After two 1510 iterations, Ben and Yakov agreed on this formulation for an update to 1511 section 3.1: 1513 Changing the attributes of a route is accomplished by advertising a 1514 replacement route. The replacement route carries new (changed) 1515 attributes and has the same NLRI as the original route. 1517 Jeff objected somewhat to the wording, since, because of a bgp route 1518 is defined as a pair, changing either part of 1519 that pair, by definition, changes the route. He acknowledged that 1520 this might fall under the category of implementation detail. 1522 Yakov presented the view that he thought we were at consensus with 1523 the text he proposed above. Jonathan agreed. There were no 1524 objections, so this is moved to Consensus. 1526 2.25. NEXT_HOP Semantics 1528 Status: Consensus 1529 Change: No 1530 Summary: After responders pointed out another sentence, this comment 1531 was resolved. Things will stay the way they are. 1533 Discussion: 1535 1. P.28, 2nd to last paragraph. The line that reads, "To be 1536 semantically correct, the IP address in the NEXT_HOP must not be the 1537 IP address of the receiving speaker, and the NEXT_HOP IP address must 1538 either be the sender's IP address (used to establish the BGP 1539 session), or the interface associated with the NEXT_HOP IP address 1540 must share a common subnet with the receiving BGP speaker..." 1542 This is not always true, what if the current ASBR BGP router is 1543 advertising an external AS route (to a IBGP Peer) whose NEXT_HOP IP 1544 address is the IP address of the EBGP peer in the other AS? 1546 A response to this pointed out that right before this is a sentence 1547 stating that this only applied to eBGP links, and only when the peers 1548 are one hop from each other, so a modification is unnecessary. This 1549 response was confirmed with another. 1551 The original reviewer acknowledged this and withdrew the comment. 1553 The consensus is to leave things the way they are. 1555 2.26. Attributes with Multiple Prefixes 1557 Status: Consensus 1558 Change: No 1559 Summary: After some discussion, the consensus is to keep things the 1560 same since the suggested behavior is defined in the message format. 1562 Discussion: 1564 2. P. 29, Section 6.3. Add this rule near the attribute rules. 1565 "Multiple prefixes that require the same attribute type with 1566 different values must never appear in the same update message". 1568 A response to this suggested that this text is unnecessary since this 1569 behavior is ruled out by the way the message format is defined. 1571 The original commenter agrees with the responder. The consensus is 1572 to leave things the way they are. 1574 2.27. Allow All Non-Destructive Messages to Refresh Hold Timer 1576 Status: Consensus 1577 Change: No 1578 Summary: It is agreed that this is a change that exceeds the original 1579 goal of this draft revision. This goal is to document existing 1580 practice in an interoperable way. 1582 Discussion: 1584 3. P. 29, Section 6.5, Please rewrite this sentence from: "If a 1585 system does not receive successive KEEPALIVE and/or UPDATE and/or 1586 NOTIFICATION messages within the period specified in the Hold Time 1587 field of the OPEN message ..." 1589 To This: "If a system does not receive successive KEEPALIVE and/or 1590 UPDATE and/or any other BGP message within the period specified in 1591 the Hold Time field of the OPEN message ..." 1593 There is disagreement on this change. It has been discussed in other 1594 threads. 1596 The original commenter acknowledged that this is something that would 1597 be "adding a new feature" as opposed to the stated goal of 1598 "documenting what exists." He suggested that the ADs decide if we 1599 should open the door for new features or not. 1601 Yakov replied to this that he would suggest we keep things as is, 1602 since the purpose is to document current implementations. 1604 This did not meet with any objections, so this issue has been moved 1605 into consensus. 1607 2.28. BGP Identifier as Variable Quantity 1609 Status: Consensus 1610 Change: No 1611 Summary: The consensus is that changing the BGP Identifier in the 1612 base draft is out-of-scope at this point in the draft evolution. 1614 Discussion: 1616 4. P. 31, section 6.8, Please rewrite this sentence from: "Comparing 1617 BGP Identifiers is done by treating them as (4-octet long) unsigned 1618 integers." 1620 To This: "Comparing BGP Identifiers is done by treating them as large 1621 numbers based on their IP Address type (e.g. IPv4, IPv6, etc.)." 1623 A response to this was that since BGP Identifier is defined in the 1624 base spec as a 4 byte unsigned integer, and not a variable quantity, 1625 the sentence as written is acceptable. This was also confirmed by 1626 another response. 1628 The original commenter was thinking of IPv6, and providing sufficient 1629 space to allow a full v6 address to be used. 1631 Again, responders said that this is out-of-scope for the current 1632 draft. 1634 2.29. State Why Unresolveable Routes Should Be Kept in Adj-RIB-In 1636 Status: Consensus 1637 Change: Yes 1638 Summary: Add: 1640 "in case they become resolvable" after the last sentence on p. 46. 1642 Discussion: 1644 5. P.46, last sentence, "However, corresponding unresolvable routes 1645 SHOULD be kept in the Adj-RIBs-In." It would helpful if the author 1646 states why unresolvable routes should be kept in Adj-RIBs-In? 1648 A response to this stated "In case they become resolvable" 1650 Yakov responded that: 1652 I suggest we add "in case they become resolvable" after the last 1653 sentence on p. 46. 1655 The original commenter stated that: Then the point that the peer will 1656 not refresh the route if we drop them (unless we use Route Refresh) 1657 because they are unreachable should be made. 1659 Yakov also responded that: 1661 This should be clear from the following text in Section 3: 1663 The initial data flow is the portion of the BGP routing table that is 1664 allowed by the export policy, called the Adj-Ribs-Out (see 3.2). 1665 Incremental updates are sent as the routing tables change. BGP does 1666 not require periodic refresh of the routing table. 1668 Jonathan, who was the original commenter, agreed with both the 1669 changed text and the clarity of section 3. 1671 2.30. Mention Other Message Types 1673 Status: Consensus 1674 Change: Yes 1675 Summary: Add a reference to RFC2918 at the end of the type code list. 1677 Discussion: 1679 1. P. 7 Type: Need to add the new message types such as, Capability 1680 Negotiations (RFC2842), Route Refresh, etc. 1682 One response argued that these are out-of-scope of the base document. 1683 One response agreed, but thought that it should be capability and not 1684 message type. The original commenter responded about Message type 1685 from the capability draft. 1687 Sue mentioned this would be added in the second round. 1689 Yakov replied that: 1691 The only new message type that is covered by an RFC (rather than just 1692 an Internet Draft) is the Refresh message. With this in mind how 1693 about replacing the following: 1695 The following type codes are defined: 1697 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE 1699 with 1700 This document defines the following type codes: 1702 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE 1704 [RFC2918] defines one more type code. 1706 Jonathan agreed with this change. This issue has been moved to 1707 consensus. 1709 2.31. Add References to Additional Options 1711 Status: Consensus 1712 Change: Yes 1713 Summary: Consensus to add: 1715 [RFC2842] defines another Optional Parameter. 1717 Discussion: 1719 2. P. 9, right after "This document defines the following optional 1720 parameters:" Need to mention possible options, such as: Capabilities 1721 (RFC2842), Multiprotocol extensions (RFC2858), Route Refresh 1722 (RFC2918). 1724 One response agreed that adding references would be fine. A second 1725 response agreed. 1727 Yakov replied that: 1729 Please note that only rfc2842 defines an OPEN optional parameter. 1730 Neither rfc2858 nor rfc2918 defines an OPEN optional parameter. 1732 With this in mind I would suggest to add the following text: 1734 [RFC2842] defines another Optional Parameter. 1736 The original poster agreed with this modification. This issue is at 1737 consensus. 1739 2.32. Clarify EGP Reference 1741 Status: Consensus 1742 Change: No 1743 Summary: The consensus is that this was addressed in 32.1, so we can 1744 close this. 1746 Discussion: 1748 3. P. 13, EGP, are there other EGP protocols other than BGP that are 1749 in use? If not, change EGP to BGP. 1751 A response to this suggested that we add a reference to [1] (the EGP 1752 spec) here. 1754 Another response clarified that this refers to EGP-the-protocol and 1755 NOT the class. 1757 Another response disagreed, but suggested that: 1759 IGP = network was explicitly introduced into bgp (network cmd) 1760 INCOMPLETE = network was implicitly introduced into bgp 1761 (redistribute) EGP = other 1763 The original commenter thought that this referred to EGP-the-class of 1764 protocols. And why not use BGP therefore, as the only EGP. 1766 There was some discussion over whether or not we should mention 1767 something that is historical. 1769 Jeff suggested a footnote in the Origin section about EGP. 1771 Curtis suggested that we state that the EGP in ORIGIN is deprecated, 1772 but retain the value to document what it used to mean. 1774 This reviewer thinks a statement about whether this "EGP" origin 1775 refers to the protocol or the class or protocols would be useful. 1777 Yakov replied that an EGP reference will be added (see issue 9). 1779 Yakov also stated that he doesn't see what is wrong with the current 1780 text, and suggested we keep it. This includes leaving out any 1781 reference to the status of the EGP spec. He sees that it is clear 1782 from context that we are talking about "the EGP" [RFC904]. 1784 Jeff noted that this issue has been sufficiently addressed in the 1785 solution to 32.1. This met with agreement. We are at consensus. 1787 2.32.1. EGP ORIGIN Clarification 1789 Status: Consensus 1790 Change: Yes 1791 Summary: Change section 5.1.1 to read: 1793 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1794 shall be generated by the speaker that originates the associated 1795 routing information. Its value SHOULD NOT be changed by any other 1796 speaker." 1798 Consensus to change: 1800 1 EGP - Network Layer Reachability Information learned via the EGP 1801 protocol 1803 to: 1805 1 EGP - Network Layer Reachability Information learned via the EGP 1806 protocol [RFC904] 1808 Discussion: 1810 This discussion is picked up again in the "Review of 1811 draft-ietf-idr-bgp4-17" thread, where specific text is proposed: 1813 Old: 1815 "ORIGIN is a well-known mandatory attribute that defines the origin 1816 of the path information. The data octet can assume the following 1817 values: 1819 Value Meaning 1821 0 IGP - Network Layer Reachability Information is interior to the 1822 originating AS 1824 1 EGP - Network Layer Reachability Information learned via the EGP 1825 protocol 1827 2 INCOMPLETE - Network Layer Reachability Information learned by some 1828 other means" New: 1830 "ORIGIN is a well-known mandatory attribute that defines the origin 1831 of the path information. The data octet can assume the following 1832 values: 1834 Value Meaning 1836 0 IGP - NLRI was explicitly introduced into bgp 1838 1 EGP - this value was administratively configured to affect policy 1839 decisions or NLRI was learned via the EGP protocol [1] 1841 2 INCOMPLETE - NLRI was implicitly introduced into bgp" 1843 since: 1) The network command sets the origin to IGP and I remember 1844 seeing somewhere that only static routes should be set to IGP. 2) The 1845 primary use of EGP value is policy 3) EGP seems to still exist, 1846 anyway even if it does not it is not worth re-writing the world. 1848 Also, change: "5.1.1 ORIGIN 1850 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1851 shall be generated by the autonomous system that originates the 1852 associated routing information. It shall be included in the UPDATE 1853 messages of all BGP speakers that choose to propagate this 1854 information to other BGP speakers." 1856 to: "5.1.1 ORIGIN 1858 The value of the ORIGIN attribute shall be set by the speaker that 1859 originates the associated NLRI. Its value shall not be changed by 1860 any other speaker unless the other speaker is administratively 1861 configured to do so to affect policy decisions." 1863 since: 1) It is already defined as well-known mandatory attribute. 2) 1864 It may be set differently within the same AS (not saying this is 1865 good). 3) It is commonly used for policy, but by default does not get 1866 changed. 4) Speakers have no choice, it is mandatory. 1868 After much continued discussion on this in the "issue 32.1" thread, 1869 we seem to have come to a consensus that section 5.1.1 should read: 1871 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1872 shall be generated by the speaker that originates the associated 1873 routing information. Its value should not be changed by any other 1874 speaker unless the other speaker is administratively configured to do 1875 so to affect policy decisions." 1877 This text met with a number of agreements, and one disagreement 1878 stating that we shouldn't have the "unless administratively 1879 configured" portion. 1881 After some further discussion, we have this text on the table: 1883 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1884 generated by the BGP speaker that originates the associated BGP 1885 routing information. The attribute shall be included in the UPDATE 1886 messages of all BGP speakers that choose to propagate this 1887 information to other BGP speakers. 1889 Jonathan suggested that we change "propagate this information" to 1890 "forward this route". He also mentioned that he would prefer 1891 something more explicit instead of/in addition to "The attribute 1892 shall be included in the UPDATE messages of all BGP speakers that 1893 choose to propagate this information to other BGP speakers." such as 1894 "other speakers do not change the ORIGIN value." 1896 On the issue of making the EGP ORIGIN type more clear Andrew 1897 proposed: 1899 To me, there seems to be sufficient confusion around the "EGP" 1900 reference to merit some sort of clarification. The simplest 1901 modification would be to change: 1903 1 EGP - Network Layer Reachability Information learned via the EGP 1904 protocol 1906 to: 1908 1 EGP - Network Layer Reachability Information learned via the EGP 1909 protocol [RFC904] 1911 That would clarify that we're talking about the protocol, and not the 1912 class-of-protocols, or EBGP. It would leave unstated that this could 1913 theoretically be used to muck with route selection. I think that is 1914 ok. If operators want to override ORIGIN to affect some hoho magic, 1915 they are welcome to do so, but I don't think it needs to be 1916 documented in the base spec. 1918 This met with a number of agreements. 1920 On the second text section we are working on, Jonathan objected to 1921 the current working text below and suggested an alternate: 1923 CHANGE: 1925 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1926 generated by the BGP speaker that originates the associated BGP 1927 routing information. The attribute shall be included in the UPDATE 1928 messages of all BGP speakers that choose to propagate this 1929 information to other BGP speakers." 1931 TO: 1933 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1934 shall be generated by the speaker that originates the associated 1935 routing information. Its value should not be changed by any other 1936 speaker unless the other speaker is administratively configured to do 1937 so to affect policy decisions." 1939 -or- 1940 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1941 shall be generated by the speaker that originates the associated 1942 routing information. Its value should not be changed by any other 1943 speaker." 1945 Jonathan cited a recent example of someone who was still confused by 1946 this section of the text in -17 (not specifically the working text). 1948 Yakov proposed this as final text: 1950 In 4.3: 1952 a) ORIGIN (Type Code 1): 1954 ORIGIN is a well-known mandatory attribute that defines the origin of 1955 the path information. The data octet can assume the following 1956 values: 1958 Value Meaning 1960 0 IGP - Network Layer Reachability Information is interior to the 1961 originating AS 1963 1 EGP - Network Layer Reachability Information learned via the EGP 1964 protocol [RFC904] 1966 2 INCOMPLETE - Network Layer Reachability Information learned by some 1967 other means 1969 Usage of this attribute is defined in 5.1.1. 1971 In 5.1.1: 1973 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1974 shall be generated by the speaker that originates the associated 1975 routing information. Its value SHOULD NOT be changed by any other 1976 speaker." 1978 This met with agreement. This issue is at consensus. 1980 2.32.2. BGP Destination-based Forwarding Paradigm 1982 Status: Consensus 1983 Change: Yes 1984 Summary: After much discussion, this is the consensus: This text in 1985 the current draft: 1987 To characterize the set of policy decisions that can be enforced 1988 using BGP, one must focus on the rule that a BGP speaker advertises 1989 to its peers (other BGP speakers which it communicates with) in 1990 neighboring ASs only those routes that it itself uses. This rule 1991 reflects the "hop-by-hop" routing paradigm generally used throughout 1992 the current Internet. Note that some policies cannot be supported by 1993 the "hop-by-hop" routing paradigm and thus require techniques such as 1994 source routing (aka explicit routing) to enforce. For example, BGP 1995 does not enable one AS to send traffic to a neighboring AS intending 1996 that the traffic take a different route from that taken by traffic 1997 originating in the neighboring AS. On the other hand, BGP can 1998 support any policy conforming to the "hop-by-hop" routing paradigm. 1999 Since the current Internet uses only the "hop-by-hop" inter-AS 2000 routing paradigm and since BGP can support any policy that conforms 2001 to that paradigm, BGP is highly applicable as an inter-AS routing 2002 protocol for the current Internet. 2004 will be replaced in -18 with the following text: 2006 Routing information exchanged via BGP supports only the destination- 2007 based forwarding paradigm, which assumes that a router forwards a 2008 packet based solely on the destination address carried in the IP 2009 header of the packet. This, in turn, reflects the set of policy 2010 decisions that can (and can not) be enforced using BGP. Note that 2011 some policies cannot be supported by the destination-based forwarding 2012 paradigm, and thus require techniques such as source routing (aka 2013 explicit routing) to be enforced*. Such policies can not be enforced 2014 using BGP either. For example, BGP does not enable one AS to send 2015 traffic to a neighboring AS for forwarding to some destination 2016 (reachable through but) beyond that neighboring AS intending that the 2017 traffic take a different route to that taken by the traffic 2018 originating in the neighboring AS (for that same destination). On 2019 the other hand, BGP can support any policy conforming to the 2020 destination-based forwarding paradigm. 2022 Discussion: 2024 In response to these proposals, Yakov proposed that the real problem 2025 is that it is not clear that BGP is build to support the destination- 2026 based forwarding paradigm. To fix this, it was proposed that: 2028 2030 To characterize the set of policy decisions that can be enforced 2031 using BGP, one must focus on the rule that a BGP speaker advertises 2032 to its peers (other BGP speakers which it communicates with) in 2033 neighboring ASs only those routes that it itself uses. This rule 2034 reflects the "hop-by-hop" routing paradigm generally used throughout 2035 the current Internet. Note that some policies cannot be supported by 2036 the "hop-by-hop" routing paradigm and thus require techniques such as 2037 source routing (aka explicit routing) to enforce. For example, BGP 2038 does not enable one AS to send traffic to a neighboring AS intending 2039 that the traffic take a different route from that taken by traffic 2040 originating in the neighboring AS. On the other hand, BGP can 2041 support any policy conforming to the "hop-by-hop" routing paradigm. 2042 Since the current Internet uses only the "hop-by-hop" inter-AS 2043 routing paradigm and since BGP can support any policy that conforms 2044 to that paradigm, BGP is highly applicable as an inter-AS routing 2045 protocol for the current Internet. 2047 2049 Routing information exchanged via BGP supports only the destination- 2050 based forwarding paradigm, which assumes that a router forwards a 2051 packet based solely on the destination address carried in the IP 2052 header of the packet. This, in turn reflects the set of policy 2053 decisions that can (and can not) be enforced using BGP. Note that 2054 some policies cannot be supported by the destination-based forwarding 2055 paradigm and thus require techniques such as source routing (aka 2056 explicit routing) to enforce. Such policies can not be enforced 2057 using BGP either. For example, BGP does not enable one AS to send 2058 traffic to a neighboring AS intending that the traffic take a 2059 different route from that taken by traffic originating in the 2060 neighboring AS. On the other hand, BGP can support any policy 2061 conforming to the destination-based forwarding paradigm. 2063 Curtis thinks the newer text here is more clear. 2065 In response to the new text, Christian Martin proposed a slightly 2066 different new text: 2068 Routing information exchanged via BGP supports only the destination- 2069 based forwarding paradigm, which assumes that a router forwards a 2070 packet based solely on the destination address carried in the IP 2071 header of the packet. This, in turn reflects the set of policy 2072 decisions that can (and can not) be enforces using BGP. Note that 2073 some policies cannot be supported by the destination-based forwarding 2074 paradigm and thus require techniques such as source routing (aka 2075 explicit routing) to enforce. Such policies can not be enforced 2076 using BGP either. For example, BGP does not enable one AS to send 2077 traffic to a neighboring AS based on prefixes originating from the 2078 local AS. On the other hand, BGP can support any policy conforming 2079 to the destination-based forwarding paradigm. 2081 To which Yakov replied: 2083 Routing information exchanged via BGP supports only the destination- 2084 based forwarding paradigm, which assumes that a router forwards a 2085 packet based solely on the destination address carried in the IP 2086 header of the packet. This, in turn, reflects the set of policy 2087 decisions that can (and can not) be enforces using BGP. Note that 2088 some policies cannot be supported by the destination-based forwarding 2089 paradigm, and thus require techniques such as source routing (aka 2090 explicit routing) to enforce. Such policies can not be enforced 2091 using BGP either. For example, BGP does not enable one AS to send 2092 traffic through a neighboring AS to some destination (which is 2093 outside of the neighboring AS, but is reachable through the 2094 neighboring AS) intending that the traffic take a different route 2095 from that taken by the traffic to the same destination that 2096 originating in the neighboring AS. On the other hand, BGP can 2097 support any policy conforming to the destination-based forwarding 2098 paradigm. 2100 And Chris responded: 2102 Routing information exchanged via BGP supports only the destination- 2103 based forwarding paradigm, which assumes that a router forwards a 2104 packet based solely on the destination address carried in the IP 2105 header of the packet. This, in turn, reflects the set of policy 2106 decisions that can (and can not) be enforces using BGP. Note that 2107 some policies cannot be supported by the destination-based forwarding 2108 paradigm, and thus require techniques such as source routing (aka 2109 explicit routing) to enforce. Such policies can not be enforced 2110 using BGP either. For example, BGP does not enable one AS to send 2111 traffic through a neighboring AS to some destination beyond the 2112 neighboring AS intending that the traffic take a different route from 2113 that taken by traffic to the same destination which originates in the 2114 neighboring AS. In other words, the BGP policy of a local AS cannot 2115 affect the downstream (aka, away from the local AS) forwarding policy 2116 of a remote AS. On the other hand, BGP can support any policy 2117 conforming to the destination-based forwarding paradigm. 2119 Tom Petch preferred Yakov's second formulation, with these changes: 2121 policies can not be enforced using BGP either. For example, BGP does 2122 not enable one AS to send traffic ! to a neighboring AS for 2123 forwarding to some destination (reachable through but) beyond ! that 2124 neighboring AS intending that ! the traffic take a different route to 2125 that taken by the traffic ! originating in the neighboring AS (for 2126 that same destination). 2128 On the other hand, BGP can support any policy conforming to the 2129 destination-based forwarding paradigm. 2131 Yakov agreed to Tom's suggested changes. 2133 2.33. Add "Optional Non-Transitive" to the MED Section 2135 Status: Consensus 2136 Change: Yes 2137 Summary: Add "Optional Non-Transitive" to MED Section Add "well-known 2138 mandatory" to the NEXT_HOP Section 2140 Discussion: 2142 4. P.23, change the following: 2144 "The MULTI_EXIT_DISC attribute may be used on external (inter-AS) 2145 links to discriminate among multiple exit or entry points to the same 2146 neighboring AS ..." 2148 To the following: 2150 "The MULTI_EXIT_DISC is an optional non-transitive attribute which 2151 may be used on external (inter-AS) links to discriminate among 2152 multiple exit or entry points to the same neighboring AS ..." 2154 A responder disagreed, and stated reasons "covered elsewhere" 2155 Original commenter asked for reasons, since the modification seemed 2156 obvious to him. 2158 Yakov agreed to make this change in -18. 2160 Jonathan replied that: 2162 5.1.3 NEXT_HOP also, it is missing " well-known mandatory". 2164 Yakov also agreed to make this change. 2166 2.34. Timer & Counter Definition 2168 Status: Consensus 2169 Change: No 2170 Summary: No discussion, no text proposed, defaults to consensus for 2171 no change. 2173 Discussion: 2175 5. In section 8, there are a number of Timers, Counters, etc. that 2176 need to be explicitly defined before they are used by the FSM. 2177 Perhaps these definitions should go in the Glossary section. 2179 There has been no further discussion on this issue. Unless it is 2180 brought up again, this issue is in consensus, with no change. 2182 2.35. Fix Typo 2184 Status: Consensus 2185 Change: Yes 2186 Summary: Fix a Typo. No discussion, but this seem clear. 2188 Discussion: 2190 1. P. 41. Typing error, "Each time time the local system...". 2192 2.36. Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 2194 Status: Consensus 2195 Change: Yes 2196 Summary: This change requires a glossary. Yakov has committed to 2197 having a section where commonly used terms are defined in draft 18, 2198 so this issue is at consensus. 2200 Discussion: 2202 2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in 2203 the glossary, so when they are used in section 9.1, it is well 2204 understood what they are. 2206 Yakov replied: 2208 will be added to the section "Definition of commonly used terms" in 2209 -18 version. 2211 2.37. Combine "Unfeasible Routes" and "Withdrawn Routes" 2213 Status: Consensus 2214 Change: Yes 2215 Summary: Add the following terms to the "commonly used terms 2216 section": 2218 Feasible route A route that is available for use. 2220 Unfeasible route A previously advertised feasible route that is no 2221 longer available for use. 2223 Discussion: 2225 3. P. 45, Phase I, There is no definition of what are unfeasible 2226 routes? Are they the same as withdrawn routes? If so, the two 2227 should be combined to one name. 2229 Ishi replied to this that he thought that we could combine the two 2230 terms, since there is limited difference from an implementation 2231 standpoint. 2233 Yakov replied: 2235 The routes are withdrawn from service because they are unfeasible, 2236 not because they are "withdrawn". So, we need to keep the term 2237 "unfeasible" to indicate the *reason* why a route could be withdrawn. 2238 On the other hand, "withdrawn" is used as a verb, and to the best of 2239 my knowledge "unfeasible" can't be used as a verb. With this in 2240 mind, I don't think that we can combine the two into a single term. 2242 Ishi replied that he was convinced, and that the terms should stay 2243 separate. 2245 Andrew asked the list if we should define these terms in the 2246 "commonly used terms" section in draft -18. 2248 Ben replied that if we use them a lot, we should define them, and if 2249 not local definitions will suffice. 2251 There was some back and forth about the necessity of defining terms 2252 which should be obvious. 2254 mrr actually checked the doc to see if we were consistently using the 2255 terms, and found: 2257 It turns out there there is an inconsistency in the usage of the word 2258 withdrawn. 2260 Section 3.1: 2262 There are three methods by which a given BGP speaker can indicate 2263 that a route has been withdrawn from service: 2265 ... 2267 b) a replacement route with the same NLRI can be advertised, or 2269 ... 2271 Later, in the definition of Withdrawn Routes Length, we have: 2273 A value of 0 indicates that no routes are being withdrawn from 2274 service, 2276 Taken together, this could be construed as meaning that a Withdrawn 2277 Routes Length of 0 indicates that all routes included in the UPDATE 2278 represent newly feasible routes... not replacement routes. 2280 Now, it's possible that this problem has been removed by changes to 2281 the text that have not yet been incorporated in to a new draft; 2282 however, it arose because the text, for the most part, does _not_ use 2283 "withdrawn" in the standard way. Instead, it refers to routes 2284 included in the WITHDRAWN ROUTES field of an UPDATE message. 2285 Consequently, I propose defining a "withdrawn route" as follows: 2287 Withdrawn route: a route included in the WITHDRAW ROUTES field of an 2288 UPDATE message. 2290 Regardless of whether or not this definition is included, Section 3.1 2291 should be changed from: 2293 There are three methods by which a given BGP speaker can indicate 2294 that a route has been withdrawn from service: 2296 to: 2298 There are three methods by which a given BGP speaker can indicate 2299 that a route has been removed from service: 2301 or: 2303 There are three methods by which a given BGP speaker can indicate 2304 that a route is now unfeasible: 2306 After some further off-list discussion, mrr agreed that this 2307 inconsistency is extremely minor, and withdrew his comment. feasible 2308 and unfeasible route will be defined in the "commonly used terms" 2309 section to clear up any confusion. 2311 2.38. Clarify Outbound Route Text 2313 Status: Consensus 2314 Change: No 2315 Summary: Consensus that the issue was sufficiently minor to leave 2316 things alone. 2318 Discussion: 2320 4. P. 50, line, "If a route in Loc-RIB is excluded from a particular 2321 Adj-RIB-Out the previously advertised route in that Adj-RIB-Out must 2322 be withdrawn from service by means of an UPDATE message (see 9.2)." 2324 Would like to rephrase the sentence for clarity, "If a route in Loc- 2325 RIB is excluded from a particular Adj-RIB-Out and was previously 2326 advertised via Adj-RIB-Out, it must be withdrawn from service by 2327 means of an UPDATE message (see 9.2)." 2329 One comment suggested either leave it alone, or remove "via Adj-RIB- 2330 Out". 2332 The original commenter withdrew the comment. 2334 2.39. Redundant Sentence Fragments 2336 Status: Consensus 2337 Change: Yes 2338 Summary: Fix typo & parentheses. 2340 Discussion: 2342 5. P. 50, section 9.1.4, The two fragments of this sentence are 2343 redundant and don't say anything new or simplify the content. Just 2344 keep one fragment. 2346 "A route describing a smaller set of destinations (a longer prefix) 2347 is said to be more specific than a route describing a larger set of 2348 destinations (a shorted prefix); similarly, a route describing a 2349 larger set of destinations (a shorter prefix) is said to be less 2350 specific than a route describing a smaller set of destinations (a 2351 longer prefix)." 2353 There was a comment that disagreed, thinking that both "more 2354 specific" and "less specific" need to be defined. And suggested that 2355 only the third and forth parentheses need to be dropped. 2357 The original commenter agreed with the parentheses changes. 2359 Yakov agreed to drop the third and fourth parentheses in the -18 2360 version. 2362 Jonathan replied to this: 2364 Disagree, the text if fine the way it is, except you need to change 2365 "shorted" to "shorter". 2367 After minimal further discussion, it was decided we are at a 2368 consensus on this issue to fix the typo and drop the third and fourth 2369 parentheses. 2371 2.40. Section 9.2.1.1 - Per Peer vs. Per Router 2372 MinRouteAdvertisementInterval 2374 Status: Consensus 2375 Change: No 2376 Summary: The consensus is that current practice allows for the 2377 MinRouteAdvertisementInterval to be set per peer, so the text should 2378 be kept the same. 2380 Discussion: 2382 6. P. 52, section 9.2.1.1 Change this sentence for clarity, "This 2383 rate limiting procedure applies on a per-destination basis, although 2384 the value of MinRouteAdvertisementInterval is set on a per BGP peer 2385 basis." 2387 To This: "This rate limiting procedure applies on a per-destination 2388 basis, although the value of MinRouteAdvertisementInterval is set on 2389 a BGP router (same value for all peers) basis." 2391 There was a comment disagreeing with this proposal. It was later 2392 elaborated on to include that the reason for disagreement was that 2393 the proposed changes changed the protocol and not just a practice 2394 clarification. Ben responded asking for how this is a protocol 2395 change, he saw it as a clarification. Perhaps there is something 2396 deeper that needs to be clarified? Again, response to this is that 2397 current implementations allow the MinRouteAdvertisementInterval to be 2398 set per-peer, not per-router. 2400 Original reviewer conceded the point. 2402 There was some additional discussion on this point. Most of it was 2403 along the lines of extracting what was really implemented and 2404 supported among various vendors. The conclusion was the same. 2406 2.41. Mention FSM Internal Timers 2408 Status: Consensus 2409 Change: No 2410 Summary: No discussion on this issue. No text proposed. Perhaps 2411 this is in the FSM section of the draft? Either way, it defaults to 2412 consensus with no change. 2414 Discussion: 2416 7. P. 61, item 6.4. Although all the BGP protocol interfacing 2417 timers are mentioned, there are a few FSM internal timers mentioned 2418 in the spec that need to be covered here as well. 2420 There has been no discussion on this, it now defaults to consensus 2421 with no change. 2423 2.42. Delete the FSM Section 2425 Status: Consensus 2426 Change: No 2427 Summary: There was some confusion on the question: Is the FSM draft 2428 going to be a separate document, or incorporated into the base draft. 2429 The consensus is that it is going to become part of the base draft, 2430 so the FSM section will be kept, and elaborated on. 2432 Discussion: 2434 8. Since there is going to be an FSM spec, do we need to have FSM 2435 descriptions in this spec. Maybe the FSM section should be delete. 2437 There was one response agreeing with this. One response asking for 2438 clarification: Was this a move to remove section 8. Finite State 2439 Machine from the base draft?? The original reviewer said, yes, when 2440 Sue's FSM draft becomes a WG document, we should remove section 8 2441 from the base draft. Yakov asked that the AD's provide input on this 2442 suggestion. 2444 Alex responded saying that the FSM draft is going to be part of the 2445 base spec, and not another document once the FSM words are approved. 2447 2.43. Clarify the NOTIFICATION Section 2449 Status: Consensus 2450 Change: Yes 2451 Summary: Replace: 2453 "If a peer sends a NOTIFICATION message, and there is an error in 2454 that message, there is unfortunately no means of reporting this error 2455 via a subsequent NOTIFICATION message." 2457 With: 2459 If a peer sends a NOTIFICATION message, and the receiver of the 2460 message detects an error in that message, the receiver can not use a 2461 NOTIFICATION message to report this error back to the peer. 2463 Discussion: 2465 The "NOTIFICATION message error handling" thread proposed: 2467 Please change" "If a peer sends a NOTIFICATION message, and there is 2468 an error in that message, there is unfortunately no means of 2469 reporting this error via a subsequent NOTIFICATION message." 2471 To: "If a peer receives a NOTIFICATION message, and there is an error 2472 in that message, there is unfortunately no means of reporting this 2473 error via a subsequent NOTIFICATION message." 2475 This reversal of meaning met with disagreement, and this text was 2476 proposed instead: 2478 All errors detected while processing the NOTIFICATION message cannot 2479 be indicated by sending subsequent NOTIFICATION message back to 2480 originating peer, therefore there is no means of reporting 2481 NOTIFICATION message processing errors. Any error, such as an 2482 unrecognized Error Code or Error Subcode, should be noticed, logged 2483 locally, and brought to the attention of the administration of the 2484 peer that has sent the message. The means to do this, however, lies 2485 outside the scope of this document. 2487 The original posted agreed with the intent of the respondent's text, 2488 thought it was too wordy, but did not propose alternate text. 2490 Yakov replied with this proposed text: 2492 If a peer sends a NOTIFICATION message, and the receiver of the 2493 message detects an error in that message, the receiver can not use a 2494 NOTIFICATION message to report this error back to the peer. 2496 Two responses liked this new text. Unless there are objections, 2497 we'll consider that a consensus. 2499 2.44. Section 6.2: OPEN message error handling 2501 Status: Consensus 2502 Change: No 2503 Summary: One commenter observed that the spec seems to specify 2504 behavior that doesn't seem to be observed by extant implementations, 2505 and suggested modifications to the spec. They were later reminded 2506 that the base behavior is acceptable, and agreed. 2508 Discussion: 2510 The "BGP4 draft ; section 6.2" thread began with a discussion of 2511 section 6.2: OPEN message error handling. Specifically: 2513 "If one of the optional parameters in the Open message is not 2514 recognized, then the error subcode is set to 'unsupported optional 2515 parameters" 2516 We have hit on this line when we were testing a BGP connection 2517 between a speaker that supported capability negotiation and a speaker 2518 that did not. 2520 The speaker that did not support the negotiation closed down the 2521 peering session using the error clause mentioned above. Sometimes 2522 this lead to the other router to repeat the OPEN message with the 2523 Capability optional parameter; a game that went on for minutes. 2525 This router manufacturer stated in a reply to this that : "One should 2526 not close down the connection if an optional parameter is 2527 unrecognized. That would make this parameter basically mandatory. 2528 This is an well known error in the BGP spec. Neither Cisco or 2529 Juniper do this" 2531 If this is true it might be good to adapt the text. 2533 The response to this quoted RFC2842, Capabilities Advertisement with 2534 BGP-4: 2536 A BGP speaker determines that its peer doesn't support capabilities 2537 advertisement, if in response to an OPEN message that carries the 2538 Capabilities Optional Parameter, the speaker receives a NOTIFICATION 2539 message with the Error Subcode set to Unsupported Optional Parameter. 2540 In this case the speaker should attempt to re-establish a BGP 2541 connection with the peer without sending to the peer the Capabilities 2542 Optional Parameter. 2544 The original poster responded: 2546 This section from the Capabilities Advertisement RFC, is indeed 2547 inline with the section 6.2 of the BGP4 specification. For me 2548 however the question remains if most implementations do no simply 2549 ignore optional parameters that are unknown. And if so, if the text 2550 stated above reflects what is implemented by routers that do not have 2551 capability advertisement at all. 2553 Yakov replied to this with: 2555 RFC2842 assumes that a router (that doesn't implement RFC2842) would 2556 close the BGP session when the router receives an OPEN message with 2557 an unrecognized Optional Parameter. Therefore the text in the spec 2558 should be left unmodified. 2560 The original poster, Jonathan, agreed with this. This issue moves to 2561 consensus. 2563 2.45. Consistent References to BGP Peers/Connections/Sessions 2565 Status: Consensus 2566 Change: Yes 2567 Summary: Stick with "BGP Connection" as the consistent term. 2569 Discussion: 2571 Ben proposed and Yakov responded: 2573 > 1. Throughout the document we have various ways of naming the BGP 2574 > peering communication. 1) BGP Session, 2) BGP Peering Session, 2576 I'll replace "session" with "connection". 2578 > 3) TCP Connection, 2580 The spec doesn't name BGP peering communication as "TCP connection"; 2581 TCP connection is used to establish BGP connection. So, TCP 2582 connection and BGP connection are two different things. 2584 > 4) BGP Connection, 2586 The spec is going to use this term (see above). 2588 > 5) BGP Peering Connection, 2590 I'll replace "BGP peering connection" with "BGP connection". 2592 > 6) Connection, 2594 The text uses "connection" whenever it is clear from the context that 2595 it refers to "BGP connection" (or "TCP connection"). 2597 > 7) BGP Speaker Connection. 2599 I'll replace "BGP Speaker Connection" with "BGP connection". 2601 > > BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker 2603 The term "speaker" is used when it is clear from the context that we 2604 are talking about "BGP speaker". 2606 > 2. Change Internal peer to IBGP Peer. 2608 IBGP stands for "BGP connection between internal peers". Therefore 2609 the term "IBGP Peer" would mean "BGP connection between internal 2610 peers peer". That doesn't seem appropriate. 2612 This issue has had some discussion, and section 3 was referenced, 2613 specifically: 2615 Refer to Section 3 - Summary of operations which clearly states that 2616 " .. a peer in a different AS is referred to as an external peer, 2617 while a peer in the same AS may be described as an internal peer. 2618 Internal BGP and external BGP are commonly abbreviated IBGP and EBGP" 2620 After more discussion it was decided that we should modify a 2621 paragraph on page 4 to read: 2623 If a particular AS has multiple BGP speakers and is providing transit 2624 service for other ASs, then care must be taken to ensure a consistent 2625 view of routing within the AS. A consistent view of the interior 2626 routes of the AS is provided by the IGP used within the AS. For the 2627 purpose of this document, it is assumed that a consistent view of the 2628 routes exterior to the AS is provided by having all BGP speakers 2629 within the AS maintain IBGP with each other. Care must be taken to 2630 ensure that the interior routers have all been updated with transit 2631 information before the BGP speakers announce to other ASs that 2632 transit service is being provided. 2634 This change has consensus. 2636 > 3. Change External peer to EBGP Peer. 2638 Ditto. 2640 Alex responded that having explicit definitions would be nice. This 2641 ties into the general glossary suggestion (see issues 16, 34 & 36). 2643 He also suggested that: 2645 "BGP session" which works over a "TCP connection" would be closer to 2646 the terminology we're actually using now and would avoid possible 2647 confusions when people read terms like "Connection collision") 2649 This was discussed in the "Generial Editorial Comment" thread. 2651 After some further discussion, it was decided that, due to existing 2652 implementations, we should go with "BGP connection" as the consistent 2653 term. We are at consensus. 2655 2.46. FSM Connection Collision Detection 2657 Status: Consensus 2658 Change: Yes 2659 Summary: Add this to section 8: 2661 There is one FSM per connection. Prior to determining what peer a 2662 connection is associated with there may be two connections for a 2663 given peer. There should be no more than one connection per peer. 2664 The collision detection identifies the case where there is more than 2665 one connection per peer and provides guidance for which connection to 2666 get rid of. When this occurs, the corresponding FSM for the 2667 connection that is closed should be disposed of. 2669 Discussion: 2671 The original reviewer (Tom) commented that the base draft, FSM 2672 section, could use some clarification around the area of connection 2673 collision detection. Specifically, he argued that it seems like 2674 there are actually 2 FSM's depending on which one backs off in the 2675 case of a collision. He proposed this text to clear things up: 2677 "8 BGP Finite State Machine 2679 This section specifies BGP operation - between a BGP speaker and its 2680 peer over a single TCP connection - in terms of a Finite State 2681 Machine (FSM). Following is a brief summary ... "(as before) 2683 Instead of just 2685 "This section specifies BGP operation in terms of a Finite State 2686 Machine (FSM). Following is a brief summary ... "(as before). 2688 Curtis responded: 2690 There is one FSM per connection. Prior to determining what peer a 2691 connection is associated with there may be two connections for a 2692 given peer. There should be no more than one connection per peer. 2693 The collision detection identifies the case where there is more than 2694 one connection per peer and provides guidance for which connection to 2695 get rid of. When this occurs, the corresponding FSM for the 2696 connection that is closed should be disposed of. 2698 I'm not sure which document containing an FSM we should be reading at 2699 this point, but we could add the above paragraph if we need to 2700 explicitly state that the extra connection and its FSM is disposed of 2701 when a collision is detected. 2703 When a TCP accept occurs, a connection is created and an FSM is 2704 created. Prior to the point where the peer associated with the 2705 connection is known the FSM cannot be associated with a peer. The 2706 collision is a transient condition in which the rule of "one BGP 2707 session per peer" is temporarily violated and then corrected. 2709 This is discussed in the "FSM but FSM of what?" thread. 2711 Sue responded that she would be happy to add Curtis' text to section 2712 8 and solicited any additional comments. There was only one on 2713 capitalization, so this issue is at consensus. 2715 2.47. FSM - Add Explicit State Change Wording 2717 Status: Consensus 2718 Change: No 2719 Summary: A desire for explicit state change wording was expressed. 2720 No text was proposed. The assumption is that this issue has reached 2721 a happy conclusion. 2723 Discussion: 2725 The initial reviewer: 2727 In most places, the actions taken on the receipt of an event include 2728 what the new state will be or that it remains unchanged. But there 2729 are a significant number of places where this is not done (eg Connect 2730 state events 14, 15, 16). I would like to see consistency, always 2731 specify the new/unchanged state. Else I may be misreading it. 2733 There was a response asking for specific text, and offering to take 2734 the discussion private. 2736 This is discussed in the "FSM words - state changes" thread. 2738 There has been no further discussion on this. The assumption is that 2739 is has reached a happy conclusion privately. 2741 2.48. Explicitly Define Processing of Incoming Connections 2743 Status: Consensus 2744 Change: Yes 2745 Summary: Add text that is at the end of the discussion to section 8. 2747 Discussion: 2749 Alex suggested we explicitly define: 2751 - processing of incoming TCP connections (peer lookup, acceptance, 2752 FSM creation, collision control,) 2754 Curtis later proposed this text: 2756 BGP must maintain separate FSM for each configured peer. Each BGP 2757 peer paired in a potential connection will attempt to connect to the 2758 other. For the purpose of this discussions, the active or connect 2759 side of a TCP connection (the side sending the first TCP SYN packet) 2760 is called outgoing. The passive or listening side (the sender of the 2761 first SYN ACK) is called the an incoming connection. 2763 A BGP implementation must connect to and listen on TCP port 179 for 2764 incoming connections in addition to trying to connect to peers. For 2765 each incoming connection, a state machine must be instantiated. 2766 There exists a period in which the identity of the peer on the other 2767 end of an incoming connection is not known with certainty. During 2768 this time, both an incoming and outgoing connection for the same peer 2769 may exist. This is referred to as a connection collision (see 2770 Section x.x, was 6.8). 2772 A BGP implementation will have at most one FSM for each peer plus one 2773 FSM for each incoming TCP connection for which the peer has not yet 2774 been identified. Each FSM corresponds to exactly one TCP connection. 2776 Jonathan pointed out that there was an inaccuracy in the proposed 2777 text. Curtis replied with this: 2779 You're correct in that you must have a collision of IP addresses on 2780 the TCP connections and that the BGP Identifier is used only to 2781 resolve which gets dropped. 2783 The FSM stays around as long as "BGP Identifier" is not known. 2784 Replace "not known with certainty" with "known but the BGP identifier 2785 is not known" and replace "for the same peer" with "for the same 2786 configured peering". 2788 The first paragraph is unchanged: 2790 BGP must maintain separate FSM for each configured peer. Each BGP 2791 peer paired in a potential connection will attempt to connect to the 2792 other. For the purpose of this discussions, the active or connect 2793 side of a TCP connection (the side sending the first TCP SYN packet) 2794 is called outgoing. The passive or listening side (the sender of the 2795 first SYN ACK) is called the an incoming connection. 2797 The second paragraph becomes: 2799 A BGP implementation must connect to and listen on TCP port 179 for 2800 incoming connections in addition to trying to connect to peers. For 2801 each incoming connection, a state machine must be instantiated. 2802 There exists a period in which the identity of the peer on the other 2803 end of an incoming connection is known but the BGP identifier is not 2804 known. During this time, both an incoming and outgoing connection 2805 for the same configured peering may exist. This is referred to as a 2806 connection collision (see Section x.x, was 6.8). 2808 The next paragraph then needs to get fixed. Changed "for each peer" 2809 to "for each configured peering". 2811 A BGP implementation will have at most one FSM for each configured 2812 peering plus one FSM for each incoming TCP connection for which the 2813 peer has not yet been identified. Each FSM corresponds to exactly 2814 one TCP connection. 2816 Add a paragraph to further clarify the point you made. 2818 There may be more than one connection between a pair of peers if the 2819 connections are configured to use a different pair of IP addresses. 2820 This is referred to as multiple "configured peerings" to the same 2821 peer. 2823 > So multiple simultaneous BGP connection are allowed between the 2824 same two > peers, and this behavior is implemented, for example to do 2825 load balancing. 2827 Good point. 2829 I hope the corrections above cover your (entirely valid) objections. 2830 If you see any more errors please let me know. 2832 Tom replied that: 2834 I take issue with the 'will attempt to connect' which goes too far. 2836 The FSM defines events 4 and 5, 'with passive Transport 2837 establishment', so the system may wait and not attempt to connect. 2838 The exit from this state is either the receipt of an incoming TCP 2839 connection (SYN) or timer expiry. 2841 So we may have a FSM attempting to transport connect for a given 2842 source/destination IP pair or we may have an FSM not attempting to 2843 connect. (In the latter case, I do not think we can get a 2844 collision). In the latter case, an incoming connection should not 2845 generate an additional FSM. 2847 I do not believe the concept of active and passive is helpful since a 2848 given system can flip from one to the other and it does not help us 2849 to clarify the number of FSM involved.. 2851 And Curtis suggested that: 2853 Could this be corrected by replacing "will attempt to connect" with 2854 "unless configured to remain in the idle state, or configured to 2855 remain passive, will attempt to connect". We could also shorten that 2856 to "will attempt to connect unless configured otherwise". 2858 Clarification (perhaps an item for a glossary entry): The terms 2859 active and passive have been in our vocabulary for almost a decade 2860 and have proven useful. The words active and passive have slightly 2861 different meanings applied to a TCP connection or applied to a peer. 2862 There is only one active side and one passive side to any one TCP 2863 connection as per the definition below. When a BGP speaker is 2864 configured passive it will never attempt to connect. If a BGP 2865 speaker is configured active it may end up on either the active or 2866 passive side of the connection that eventually gets established. 2867 Once the TCP connection is completed, it doesn't matter which end was 2868 active and which end was passive and the only difference is which 2869 side of the TCP connection has port number 179. 2871 Tom agreed with Curtis, that he liked the "will attempt to connect 2872 unless configured otherwise" verbiage. 2874 This was discussed in the "Generial Editorial Comment" thread. 2876 Sue proposed we add the text above in section 8.2. It is summarized 2877 here for clarity: 2879 8.2) Description of FSM 2881 8.2.1) FSM connections 2883 (text below) 2885 8.2.2) FSM Definition 2887 (text now in 8.2) 2889 "BGP must maintain a separate FSM for each configured peer plus Each 2890 BGP peer paired in a potential connection unless configured to remain 2891 in the idle state, or configured to remain passive, will attempt to 2892 to connect to the other. For the purpose of this discussion, the 2893 active or connect side of the TCP connection (the side of a TCP 2894 connection (the side sending the first TCP SYN packet) is called 2895 outgoing. The passive or listening side (the sender of the first SYN 2896 ACK) is called an incoming connection. [See section on the terms 2897 active and passive below.] 2899 A BGP implementation must connect to and listen on TCP port 179 for 2900 incoming connections in addition to trying to connect to peers. Fro 2901 each incoming connection, a state machine must be instantiated. 2902 There exists a period in which the identity of the peer on the other 2903 end of an incoming connection is known but the BGP identifier is not 2904 known. During this time, both an incoming and an outgoing connection 2905 for the same configured peering may exist. This is referred to as a 2906 connection collision (see Section x.x, was 6.8). 2908 A BGP implementation will have at most one FSM for each configured 2909 peering plus one FSM for each incoming TCP connection for which the 2910 peer has not yet been identified. Each FSM corresponds to exactly 2911 one TCP connection. 2913 There may be more than one connections between a pair of peers if the 2914 connections are configured to use a different pair of IP addresses. 2915 This is referred to as multiple "configured peerings" to the same 2916 peer. 2918 8.2.1.1) Terms "active" and "passive" 2920 The terms active and passive have been in our vocabulary for almost a 2921 decade and have proven useful. The words active and passive have 2922 slightly different meanings applied to a TCP connection or applied to 2923 a peer. There is only one active side and one passive side to any 2924 one TCP connection per the definition above [and the state machine 2925 below.] When a BGP speaker is configured active it may end up on 2926 either the active or passive side of the connection that eventually 2927 gets established. Once the TCP connection is completed, it doesn't 2928 matter which end was active and which end was passive and the only 2929 difference is which side of the TCP connection has port number 179. 2931 For additional text, see issue 46. 2933 Sue solicited additional comments, the only one was on 2934 capitalization, so it would appear we are at consensus with this 2935 issue. 2937 2.49. Explicitly Define Event Generation 2939 Status: Consensus 2940 Change: No 2941 Summary: Suggested that we explicitly define BGP message processing. 2942 No text proposed. There has been no further discussion on this 2943 issue, it is assumed that the consensus is that things are ok the way 2944 they are. 2946 Discussion: 2948 Alex suggested we explicitly define: 2950 - generation of events while processing BGP messages, i.e., the text 2951 describing message processing should say where needed that a specific 2952 event for the BGP session should be generated. 2954 No text was proposed. 2956 This discussion has received no further comment. Unless someone 2957 wants to reopen it, it is assumed it has reached a happy ending. 2959 This was discussed in the "Generial Editorial Comment" thread. 2961 2.50. FSM Timers 2963 Status: Consensus 2964 Change: No 2965 Summary: Discussion tabled, because new document version rendered the 2966 discussion moot. 2968 Discussion: 2970 This discussion began with a suggestion that the timers currently in 2971 the FSM: 2973 In the 26 Aug text, I find the timer terminology still confusing. 2974 Timers can, I find, stop start restart clear set reset expire 2976 Can be cleaned up and simplified to: 2978 start with initial value (spell it out just to be sure) stop expire 2980 A response to this proposal was, that the existing set is clear, and 2981 that the proposed set is insufficiently rich to describe a concept 2982 like "reset" which encompasses: "Stop the timer, and reset it to its 2983 initial value." 2985 This discussion reached an impasse, when Sue pointed out that the 2986 text had been updated, and to please review the new text. 2988 This was discussed in the "FSM more words" thread. 2990 2.51. FSM ConnectRetryCnt 2992 Status: Consensus 2993 Change: No 2994 Summary: Discussion tabled, because new document version rendered the 2995 discussion moot. 2997 Discussion: 2999 This started with the observation that the ConnectRetryCnt "seems to 3000 have lost its purpose." It was suggested that this be made a Session 3001 Attribute, along with: OpenDelayTimer and DelayOpenFlag. 3003 Curtis explained that the current purpose of the ConnectRetryCnt is 3004 something to be read by the MIB. He also advocated against adding 3005 the additional Session Attributes. 3007 2.52. Section 3: Keeping routes in Adj-RIB-In 3009 Status: Consensus 3010 Change: Yes 3011 Summary: Add: To allow local policy changes to have the correct 3012 effect without resetting any BGP connections, a BGP speaker SHOULD 3013 either (a) retain the current version of the routes advertised to it 3014 by all of its peers for the duration of the connection, or (b) make 3015 use of the Route Refresh extension [12]. 3017 Discussion: 3019 This thread started with a question about why we should retain routes 3020 in the Adj-RIB-In, and how it relates to the Route Refresh extension. 3022 mrr proposed this text: 3024 ... Therefore, a BGP speaker must either retain the current version 3025 of the routes advertised by all of its peers for the duration of the 3026 connection, or make use of the Route Refresh extension [12]. This is 3027 necessary to allow local policy changes to have the correct effect 3028 without requiring the reset of any peering sessions. 3030 If the implementation decides not to retain the current version of 3031 the routes that have been received from a peer, then Route Refresh 3032 messages should be sent whenever there is a change to local policy. 3034 Yakov later suggested this text, with a slight rewording: 3036 To allow local policy changes to have the correct effect without 3037 resetting any BGP connections, a BGP speaker SHOULD either (a) retain 3038 the current version of the routes advertised to it by all of its 3039 peers for the duration of the connection, or (b) make use of the 3040 Route Refresh extension [12]. 3042 mrr responded that he was fine with Yakov's suggestions. 3044 This was discussed in the "Proxy: comments on section 3" thread. 3046 2.53. Section 4.3 - Routes v. Destinations - Advertise 3048 Status: Consensus 3049 Change: No 3050 Summary: The text that has reached consensus in issue 54 also 3051 addresses this issue. 3053 Discussion: 3055 This issue arose out of this question to the list: 3057 Since: 3059 "For the purpose of this protocol, a route is defined as a unit of 3060 information that pairs a set of destinations with the attributes of a 3061 path to those destinations. The set of destinations are the systems 3062 whose IP addresses are reported in the Network Layer Reachability 3063 Information (NLRI) field and the path is the information reported in 3064 the path attributes field of the same UPDATE message." 3066 When I read section 4.3: 3068 "An UPDATE message is used to advertise feasible routes sharing 3069 common path attribute to a peer, or to withdraw multiple unfeasible 3070 routes from service (see 3.1)." 3072 Shouldn't the text read "... advertise feasible [prefixes | 3073 destinations] sharing common path attribute(S)to a peer ...", 3074 because: 3076 1) A route is defined as quoted above from section 3.1? 3078 or since ... 3080 "An UPDATE message can advertise at most one set of path attributes, 3081 but multiple destinations ..." 3083 2) make "routes" in the original singular. 3085 This was discussed in the "Review Comments: Section 4.3: "routes" vs. 3086 destinations - advertise" thread. 3088 The text that has reached consensus in issue 54 also addresses this 3089 issue. 3091 2.54. Section 4.3 - Routes v. Destinations - Withdraw 3093 Status: Consensus 3094 Change: Yes 3095 Summary: Change the definition of "route" as it currently stands to: 3097 For the purpose of this protocol, a route is defined as a unit of 3098 information that pairs a set of destinations with the attributes of a 3099 path to those destinations. The set of destinations are systems 3100 whose IP addresses are contained in one IP address prefix carried in 3101 the Network Layer Reachability Information (NLRI) field of an UPDATE 3102 message and the path is the information reported in the path 3103 attributes field of the same UPDATE message. 3105 Multiple routes that have the same path attributes can be advertised 3106 in a single UPDATE message by including multiple prefixes in the NLRI 3107 field of the UPDATE message. 3109 Discussion: 3111 This issue was brought up with this question: 3113 When I read these two paragraphs at the end of section 4.3: 3115 "An UPDATE message can list multiple routes to be withdrawn from 3116 service. Each such route is identified by its destination (expressed 3117 as an IP prefix), which unambiguously identifies the route in the 3118 context of the BGP speaker - BGP speaker connection to which it has 3119 been previously advertised. 3121 An UPDATE message might advertise only routes to be withdrawn from 3122 service, in which case it will not include path attributes or Network 3123 Layer Reachability Information. Conversely, it may advertise only a 3124 feasible route, in which case the WITHDRAWN ROUTES field need not be 3125 present." 3127 It reads as if one must withdraw the _set of destinations_ advertised 3128 with the route instead of just one or more destinations since route 3129 is defined in section 3.1 as: 3131 "For the purpose of this protocol, a route is defined as a unit of 3132 information that pairs a set of destinations with the attributes of a 3133 path to those destinations. The set of destinations are the systems 3134 whose IP addresses are reported in the Network Layer Reachability 3135 Information (NLRI) field and the path is the information reported in 3136 the path attributes field of the same UPDATE message." 3138 Shouldn't the text change "routes" to destinations, or to prefixes? 3139 The original commenter added this clarification later: 3141 I meant to say, the *same* set of destinations as those advertised 3142 initially. For example, NLRI with dest-a, dest-b and dest-c with the 3143 same attributes is a "route". The withdrawal of the "route" can be 3144 read as one must withdraw all destinations originally advertised for 3145 that route (dest-a, dest-b, dest-c) as a unit. 3147 A first time reader could be left wondering if the above must be the 3148 case, or it is valid for an implementation to withdraw just one of 3149 these destinations (e.g. dest-b), leaving the others (dest-a, dest-c) 3150 reachable with their attributes intact. 3152 If there is no relationship between destinations when advertised as a 3153 set of destinations in a route and those destinations that can be 3154 withdrawn should be explicitly stated. Otherwise, the draft should 3155 call out that it is not legal to withdraw one prefix only in the set 3156 of prefixes advertised as previously as route. 3158 Matt suggested that since the definition seems to cause some 3159 confusion, that we update the definition to: 3161 "For the purpose of this protocol, a route is defined as a unit of 3162 information that pairs a set of destinations with the attributes of a 3163 path to those destinations. The set of destinations are systems 3164 whose IP addresses are reported in one prefix present in the Network 3165 Layer Reachability Information (NLRI) field of an UPDATE and the path 3166 is the information reported in the path attributes field of the same 3167 UPDATE message. 3169 This definition allows multiple routes to be advertised in a single 3170 UPDATE message by including multiple prefixes in the NLRI field of 3171 the UPDATE. All such prefixes must be associated with the same set 3172 of path attributes." 3174 Yakov suggested some minor rewording: 3176 For the purpose of this protocol, a route is defined as a unit of 3177 information that pairs a set of destinations with the attributes of a 3178 path to those destinations. The set of destinations are systems 3179 whose IP addresses are contained in one IP address prefix carried in 3180 the Network Layer Reachability Information (NLRI) field of an UPDATE 3181 message and the path is the information reported in the path 3182 attributes field of the same UPDATE message. 3184 Multiple routes that have the same path attributes can be advertised 3185 in a single UPDATE message by including multiple prefixes in the NLRI 3186 field of the UPDATE message. 3188 Both Jeff and Matt responded that they liked this text. 3190 2.55. Section 4.3 - Description of AS_PATH length 3192 Status: Consensus 3193 Change: Yes 3194 Summary: Replace: 3196 Path segment length is a 1-octet long field containing the number of 3197 ASs in the path segment value field. 3199 With: 3201 Path segment length is a 1-octet long field containing the number of 3202 ASs (not the number of octets) in the path segment value field. 3204 Discussion: 3206 This question was raised: 3208 Length fields elsewhere in the draft specify the number of bytes that 3209 a variable length field uses. For AS_PATH, length is used as the 3210 number of 2 byte AS numbers. In the interest of not having to check 3211 other sources to be sure, should the description of path segment 3212 value: 3214 "The path segment value field contains one or more AS numbers, each 3215 encoded as a 2-octets long field." 3217 explicitly mention the number of bytes used by the variable length 3218 field? 3220 Or, make the description of length explicitly mention that it is not 3221 the length of the variable length field as is the case with other 3222 length fields? 3224 One response to this agreed that some more clarification would be 3225 good, specifically an ASCII art diagram. No diagram was proposed. 3227 Yakov proposed this change: 3229 How about replacing 3231 Path segment length is a 1-octet long field containing the number of 3232 ASs in the path segment value field. 3234 with the following 3235 Path segment length is a 1-octet long field containing the number of 3236 ASs (but not the number of octets) in the path segment value field. 3238 Jonathan offered this text: 3240 How about: "Path segment length is a 1-octet long field containing 3241 the number of ASs (which is half the number of octets since each AS 3242 is 2 octets) in the path segment value field (also note that the path 3243 may contain more than 1 segment). 3245 Jeff replied that he preferred Yakov's text, but without the "but". 3246 Yakov agreed to that. Andrew also agreed, and asked if there were 3247 any objections to moving this issue into consensus. There were no 3248 objections. 3250 2.56. Section 6 - BGP Error Handling 3252 Status: Consensus 3253 Change: Yes 3254 Summary: There are a variety of updates to the text that are best 3255 described in the discussion section. 3257 Discussion: 3259 This discussion began with some suggestions on ways to clarify the 3260 text in section 6 dealing with error handling. The original 3261 comments, and Yakov's response are below: 3263 > At the beginning of Section 6. BGP Error Handling: 3264 > 3265 > 3266 > "When any of the conditions described here are detected, a 3267 > NOTIFICATION message with the indicated Error Code, Error Subcode, 3268 > and Data fields is sent, and the BGP connection is closed." 3269 > 3270 > There are several cases where the conditions described in this 3271 section 3272 > do not result in the BGP connection being closed. These conditions 3273 > should either state that the connection stays up. Another 3274 possibility 3275 > is to remove "and the BGP connection is closed." above, and for 3276 each 3277 > listed connection, state what happens to the BGP connection. This 3278 > already takes place for certain conditions, but isn't done 3279 consistently. 3281 How about replacing the above with the following: 3283 When any of the conditions described here are detected, a 3284 NOTIFICATION message with the indicated Error Code, Error Subcode, 3285 and Data fields is sent, and the BGP connection is closed, unless it 3286 is explicitly stated that no NOTIFICATION message is to be sent and 3287 the BGP connection is not to be close. 3289 > I tried to list what I found (which may be wrong or incomplete) 3290 below: 3291 > 3292 > 3293 > "If the NEXT_HOP attribute is semantically incorrect, the error 3294 should 3295 > be logged, and the route should be ignored. In this case, no 3296 > NOTIFICATION message should be sent." 3297 > 3298 > * Append the connection is not closed. 3300 Done. 3302 > 3303 > "(a) discard new address prefixes from the neighbor, or (b) 3304 terminate 3305 > the BGP peering with the neighbor." 3306 > 3307 > * Append "the connection is not closed" to case (a) 3309 added "(while maintaining BGP peering with the neighbor)" to case 3310 (a). 3312 > 3313 > "If the autonomous system number appears in the AS path the 3314 > route may be stored in the Adj-RIB-In," 3315 > 3316 > * append and the BGP connection stays up. 3317 > 3318 > "but unless the router is configured to accept routes with its 3319 > own autonomous system in the AS path, the route shall not be 3320 > passed to the BGP Decision Process." 3322 I would suggest to move this text to Section 9 (UPDATE message 3323 handling), as receiving a route with your own AS in the AS path isn't 3324 really an error. It is just that usually (but not always) you can't 3325 put this route in your Adj-RIB-In. 3327 > * Q1) does the BGP connection stay up? 3329 yes. 3331 > * Q2) what if the router isn't configured to accept routes with its 3332 > own AS in the AS path? One _may_ store the route in Adj-RIB-In, 3333 but 3334 > if one doesn't want to? 3336 So, don't store them. 3338 > Is the BGP connection closed? If so, what subcode? 3340 The connection is *not* closed. 3342 > "If an optional attribute is recognized, then the value of this 3343 > attribute is checked. If an error is detected, the attribute is 3344 > discarded, and the Error Subcode is set to Optional Attribute 3345 Error. 3346 > The Data field contains the attribute (type, length and value)." 3347 > 3348 > * Append and the BGP connection stays up after "the attribute is 3349 discarded". 3351 Since you have to close the connection, you have to discard all the 3352 routes received via this connection, including the route with the 3353 incorrect attribute. So, there is no need to say that "the attribute 3354 is discarded". 3356 There have been no objections to the updates listed above. This 3357 issue seems to have reached a happy ending, so it has been moved into 3358 consensus. 3360 This was discussed in the "-17 review Section 6 - BGP Error 3361 Handling." thread. 3363 2.57. Section 6.2 - Hold timer as Zero 3365 Status: Consensus 3366 Change: No 3367 Summary: It was suggested that we update the text to say that we MUST 3368 reject hold time values of zero. It was pointed out that this is not 3369 the case and the text should say the way it is. 3371 Discussion: 3373 In Section 6.2 on OPEN message error handling: 3375 If the Hold Time field of the OPEN message is unacceptable, then the 3376 Error Subcode MUST be set to Unacceptable Hold Time. An 3377 implementation MUST reject Hold Time values of one or two seconds. 3379 I feel that text similar to: 3381 "An implementation MUST also reject Hold Time values of zero received 3382 from a peer in a different AS" should be considered for completeness. 3384 A number of respondents pointed out that zero hold time is legitimate 3385 under certain circumstances. 3387 This was discussed in the "-17 review, Section 6.2 - must reject hold 3388 time" thread. 3390 2.58. Deprecation of ATOMIC_AGGREGATE 3392 Status: Consensus 3393 Change: Yes 3394 Summary: For new text, please see the end of the discussion. 3396 Discussion: 3398 Jeff opened this discussion with: 3400 Deprecation of ATOMIC_AGGREGATE: 3402 [This is a summary of some discussions from those who have "been 3403 there, done that" during the CIDR deployment period and also comments 3404 from network operators on the NANOG list.] 3406 When BGP-4 was originally drafted, the topic of aggregation was new 3407 enough that people didn't exactly know how it would be used. 3408 Additionally, there were some transition issues when aggregated 3409 networks would need to be de-aggregated and re-advertised into a 3410 classful routing mesh such as BGP-3. 3412 The ATOMIC_AGGREGATE flag was intended to prevent a route from being 3413 de-aggregated when de-aggregation would introduce routing loops. 3414 Note that de-aggregation in this context specifically means making a 3415 less specific route into one or more more-specific routes. 3417 The current BGP draft has two situations where ATOMIC_AGGREGATE 3418 should be appended to a route: 1. When a route's AS_PATH is 3419 intentionally truncated, such as what happens by default on Cisco's, 3420 or using the "brief" option on GateD. Juniper has a similar feature 3421 - I'm unsure of the default. 2. When two routes are implicitly 3422 aggregated in the LocRib such that a more specific route is not 3423 selected when a less specific route is from a given peer. 3425 Note that this particular feature is not implemented anywhere that I 3426 am aware of. 3428 3. There is a third case not covered by the specification: Implicit 3429 aggregation on export - a more specific route is not exported and 3430 only a less specific one is. 3432 When network operators were asked about de-aggregation practices, I 3433 received about 40 responses. The majority of these responses 3434 confused de-aggregation with leaking existing more-specific routes 3435 that are used internally rather than explicitly de-aggregating a 3436 less-specific route. 3438 There were a very few cases of explicit de-aggregation. One form was 3439 done for purposes of dealing with another ISP creating a routing DoS 3440 by advertising IP space that didn't belong to them - leaked more 3441 specifics alleviated the problem in many cases. (Note that this is a 3442 security issue in the routing system.) 3444 The second case was de-aggregating routes internally (and sending the 3445 routes via IBGP marked with NO-ADVERTISE) for purposes of traffic 3446 engineering routing internally where a given upstream failed to 3447 provide enough routing information to allow traffic flows to be 3448 optimized based on supplied prefixes. 3450 My conclusions to this are: 1. De-aggregation is not a common 3451 practice. 2. It is no longer a major concern since classful inter- 3452 domain routing is pretty much gone. 3. The spec doesn't match 3453 reality and should be corrected. 3455 My suggestions are thus this: Section 5.1.6 should be updated as 3456 follows: ATOMIC_AGGREGATE is a well-known discretionary attribute. 3457 Its use is deprecated. 3459 When a router explicitly aggregates several routes for the purpose of 3460 advertisement to a particular peer, and the AS_PATH of the aggregated 3461 route excludes at least some of the AS numbers present in the AS_PATH 3462 of the routes that are aggregated (usually due to truncation), the 3463 aggregated route, when advertised to the peer, MUST include the 3464 ATOMIC_AGGREGATE attribute. 3466 Section 9.1.4 should be updated as follows: 3467 Original text: If a BGP speaker receives overlapping routes, the 3468 Decision Process MUST consider both routes based on the configured 3469 acceptance policy. If both a less and a more specific route are 3470 accepted, then the Decision Process MUST either install both the less 3471 and the more specific routes or it MUST aggregate the two routes and 3472 install the aggregated route, provided that both routes have the same 3473 value of the NEXT_HOP attribute. 3475 If a BGP speaker chooses to aggregate, then it MUST add 3476 ATOMIC_AGGREGATE attribute to the route. A route that carries 3477 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3478 NLRI of this route can not be made more specific. Forwarding along 3479 such a route does not guarantee that IP packets will actually 3480 traverse only ASs listed in the AS_PATH attribute of the route. 3482 Replace with: 3484 It is common practice that more specific routes are often implicitly 3485 aggregated by selecting or advertising only a less-specific route 3486 when overlapping routes are present. As such, all routes SHOULD be 3487 treated as if ATOMIC_AGGREGATE is present and not be made more 3488 specific (de-aggregated). De-aggregation may lead to routing loops. 3490 Section 9.2.2 should remain as it is. 3492 Implications of not making the above updates: 3493 ATOMIC_AGGREGATE is not implemented as documented. Current 3494 operational practices do not seem to often trigger situations that it 3495 was intended to re-mediate. After all, by the way it is currently 3496 documented, many of the routes in the Internet would likely have 3497 ATOMIC_AGGREGATE. 3499 The original motivation for this investigation (aside from a few 3500 years of wondering what this portion of the spec *really* meant) was 3501 making sure the MIB is correctly documented. I can do this now, even 3502 if the spec is not corrected by simply noting that the values: 3503 lessSpecificRouteNotSelected(1), 3504 lessSpecificRouteSelected(2) 3506 mean: 3507 ATOMIC_AGGREGATE not present 3508 ATOMIC_AGGREGATE present 3510 rather than documenting anything about less and more specific routes. 3512 The v2MIB can be fixed to just call it what it is since it hasn't 3513 been RFC'ed yet. 3515 Lastly, the spec would just be incorrect. But all said, nothing bad 3516 would really come of this. 3518 Yakov responded to this, saying that he thought these changes were 3519 reasonable, and unless there were objections, they would be adopted. 3521 Ishi strongly agreed with the changes. 3523 Curtis stated that: 3525 We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated 3526 rather than replaced with an AS_SET. It was always purely 3527 informational since no one intentionally deaggregated and 3528 reannounced. 3530 And suggested that we remove the MUSTs and indicated that this is 3531 only informational. 3533 Jeff replied that: 3535 The point is that by definition of the attribute, anywhere that 3536 policy is used (and some places where it may not be), 3537 ATOMIC_AGGREGATE *should* be there. Since its not, and it would 3538 generally be everywhere, you just shouldn't de-aggregate. 3540 At best, leaving it as a method of informationally signalling 3541 truncation of a AS_PATH is the best we'll get out of it - and it 3542 matches current implementations. 3544 Jonathan agreed with Curtis' idea that we should just move 3545 ATOMIC_AGGREGATE to informational. 3547 Curtis proposed this text: 3549 This existing text is fine: 3551 f) ATOMIC_AGGREGATE (Type Code 6) 3553 ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0. 3554 Usage of this attribute is described in 5.1.6. 3556 This is the existing text that we are considering changing: 3558 5.1.6 ATOMIC_AGGREGATE 3560 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3562 When a router aggregates several routes for the purpose of 3563 advertisement to a particular peer, and the AS_PATH of the aggregated 3564 route excludes at least some of the AS numbers present in the AS_PATH 3565 of the routes that are aggregated, the aggregated route, when 3566 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3568 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3569 attribute MUST NOT remove the attribute from the route when 3570 propagating it to other speakers. 3572 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3573 attribute MUST NOT make any NLRI of that route more specific (as 3574 defined in 9.1.4) when advertising this route to other BGP speakers. 3576 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3577 attribute needs to be cognizant of the fact that the actual path to 3578 destinations, as specified in the NLRI of the route, while having the 3579 loop-free property, may not be the path specified in the AS_PATH 3580 attribute of the route. 3582 Suggested new text: 3584 5.1.6 ATOMIC_AGGREGATE 3586 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3588 When a router aggregates several routes for the purpose of 3589 advertisement to a particular peer, the AS_PATH of the aggregated 3590 route normally includes an AS_SET formed from the set of AS from 3591 which the aggregate was formed. In many cases the network 3592 administrator can determine that the aggregate can safely be 3593 advertised without the AS_SET and not form route loops. 3595 If an aggregate excludes at least some of the AS numbers present in 3596 the AS_PATH of the routes that are aggregated as a result of dropping 3597 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3598 include the ATOMIC_AGGREGATE attribute. 3600 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3601 attribute SHOULD NOT remove the attribute from the route when 3602 propagating it to other speakers. 3604 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3605 attribute MUST NOT make any NLRI of that route more specific (as 3606 defined in 9.1.4) when advertising this route to other BGP speakers. 3608 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3609 attribute needs to be cognizant of the fact that the actual path to 3610 destinations, as specified in the NLRI of the route, while having the 3611 loop-free property, may not be the path specified in the AS_PATH 3612 attribute of the route. 3614 Diffs (for reader convenience): 3616 @@ -4,13 +4,19 @@ ATOMIC_AGGREGATE is a well-known discretionary 3617 attribute. 3619 When a router aggregates several routes for the purpose of 3620 - advertisement to a particular peer, and the AS_PATH of the 3621 - aggregated route excludes at least some of the AS numbers 3622 - present in the AS_PATH of the routes that are aggregated, 3623 - the aggregated route, when advertised to the peer, MUST 3624 - include the ATOMIC_AGGREGATE attribute. 3625 + advertisement to a particular peer, the AS_PATH of the 3626 + aggregated route normally includes an AS_SET formed from the 3627 + set of AS from which the aggregate was formed. In many cases 3628 + the network administrator can determine that the aggregate can 3629 + safely be advertised without the AS_SET and not form route loops. 3630 + 3631 + If an aggregate excludes at least some of the AS numbers present 3632 + in the AS_PATH of the routes that are aggregated as a result of 3633 + dropping the AS_SET, the aggregated route, when advertised to the 3634 + peer, SHOULD include the ATOMIC_AGGREGATE attribute. 3636 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3637 - attribute MUST NOT remove the attribute from the route when 3638 + attribute SHOULD NOT remove the attribute from the route when 3639 + propagating it to other speakers. 3641 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3643 Current text in 9.1.4: 3645 If a BGP speaker chooses to aggregate, then it MUST add 3646 ATOMIC_AGGREGATE attribute to the route. A route that carries 3647 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3648 NLRI of this route can not be made more specific. Forwarding along 3649 such a route does not guarantee that IP packets will actually 3650 traverse only ASs listed in the AS_PATH attribute of the route. 3652 Change to: 3654 If a BGP speaker chooses to aggregate, then it SHOULD either include 3655 all AS used to form the aggregate in an AS_SET or add the 3656 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3657 primarily informational. With the elimination of IP routing 3658 protocols that do not support classless routing and the elimination 3659 of router and host implementations that do not support classless 3660 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3661 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3662 particular MUST NOT be de-aggregated. That is, the NLRI of this 3663 route can not be made more specific. Forwarding along such a route 3664 does not guarantee that IP packets will actually traverse only ASs 3665 listed in the AS_PATH attribute of the route. 3667 This text in 9.2.2.2 need not change. 3669 ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has 3670 ATOMIC_AGGREGATE path attribute, then the aggregated route shall have 3671 this attribute as well. 3673 The appendix need not change: 3675 Appendix 1. Comparison with RFC1771 3677 [...] 3679 Clarifications to the use of the ATOMIC_AGGREGATE attribute. 3681 This might be a bit more wordy that is necessary. It does address 3682 the objections to keeping ATOMIC_AGGREGATE by making the MUST into 3683 SHOULD, and explaining that ATOMIC_AGGREGATE is now primarily 3684 informational. 3686 Yakov was fine with this text. 3688 Yakov posted the text that represents the WG consensus: 3690 Replace: 3692 5.1.6 ATOMIC_AGGREGATE 3694 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3696 When a router aggregates several routes for the purpose of 3697 advertisement to a particular peer, and the AS_PATH of the aggregated 3698 route excludes at least some of the AS numbers present in the AS_PATH 3699 of the routes that are aggregated, the aggregated route, when 3700 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3702 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3703 attribute MUST NOT remove the attribute from the route when 3704 propagating it to other speakers. 3706 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3707 attribute MUST NOT make any NLRI of that route more specific (as 3708 defined in 9.1.4) when advertising this route to other BGP speakers. 3710 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3711 attribute needs to be cognizant of the fact that the actual path to 3712 destinations, as specified in the NLRI of the route, while having the 3713 loop-free property, may not be the path specified in the AS_PATH 3714 attribute of the route. 3716 with: 3718 5.1.6 ATOMIC_AGGREGATE 3720 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3722 When a router aggregates several routes for the purpose of 3723 advertisement to a particular peer, the AS_PATH of the aggregated 3724 route normally includes an AS_SET formed from the set of AS from 3725 which the aggregate was formed. In many cases the network 3726 administrator can determine that the aggregate can safely be 3727 advertised without the AS_SET and not form route loops. 3729 If an aggregate excludes at least some of the AS numbers present in 3730 the AS_PATH of the routes that are aggregated as a result of dropping 3731 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3732 include the ATOMIC_AGGREGATE attribute. 3734 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3735 attribute SHOULD NOT remove the attribute from the route when 3736 propagating it to other speakers. 3738 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3739 attribute MUST NOT make any NLRI of that route more specific (as 3740 defined in 9.1.4) when advertising this route to other BGP speakers. 3742 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3743 attribute needs to be cognizant of the fact that the actual path to 3744 destinations, as specified in the NLRI of the route, while having the 3745 loop-free property, may not be the path specified in the AS_PATH 3746 attribute of the route. 3748 In 9.1.4 replace: 3750 If a BGP speaker chooses to aggregate, then it MUST add 3751 ATOMIC_AGGREGATE attribute to the route. A route that carries 3752 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3753 NLRI of this route can not be made more specific. Forwarding along 3754 such a route does not guarantee that IP packets will actually 3755 traverse only ASs listed in the AS_PATH attribute of the route. 3757 with: 3759 If a BGP speaker chooses to aggregate, then it SHOULD either include 3760 all AS used to form the aggregate in an AS_SET or add the 3761 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3762 primarily informational. With the elimination of IP routing 3763 protocols that do not support classless routing and the elimination 3764 of router and host implementations that do not support classless 3765 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3766 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3767 particular MUST NOT be de-aggregated. That is, the NLRI of this 3768 route can not be made more specific. Forwarding along such a route 3769 does not guarantee that IP packets will actually traverse only ASs 3770 listed in the AS_PATH attribute of the route. 3772 This met with agreement. This issue is at consensus. 3774 2.59. Section 4.3 - Move text 3776 Status: Consensus 3777 Change: Yes (minimal) 3778 Summary: Update indentation to allow a new "subsection" heading. 3779 Otherwise no change. 3781 Discussion: 3783 This began with this suggestion: 3785 The text about the minimum length, at first look, gives the 3786 impression that it is still part of the NLRI field description and/or 3787 the Path Attributes section. A new "subsection" or heading of some 3788 sort would be helpful in switching context back to the UPDATE message 3789 as a whole and not the path attributes field anymore. 3791 Yakov agreed to update the indentation. 3793 Jonathan agreed, and suggested this text: 3795 " The minimum length of the UPDATE message is 23 octets -- 19 octets 3796 for the fixed header + 2 octets for the Withdrawn Routes Length + 2 3797 octets for the Total Path Attribute Length (the value of Withdrawn 3798 Routes Length is 0 and the value of Total Path Attribute Length is 3799 0)." 3801 Should be moved up to just after 3803 "... the Total Path Attribute Length field and the Withdrawn Routes 3804 Length field." 3806 Yakov responded to this with: 3808 Disagree, as "... the Total Path Attribute Length field and the 3809 Withdrawn Routes Length field." explains how to calculate the length 3810 of NLRI field (and therefore is part of the NLRI field description), 3811 while "The minimum length of the UPDATE message is 23 octets...." has 3812 to do with the length of the UPDATE message. 3814 Jonathan also suggested: 3816 " the value of Withdrawn Routes Length is 0 and the value of Total 3817 Path Attribute Length is 0)." 3819 Should be changed to 3821 " the min. value of Withdrawn Routes Length is 0 and the min. value 3822 of Total Path Attribute Length is 0)." 3824 And Yakov responded with: 3826 Disagree, as the text doesn't talk about what is the minimum value of 3827 the Withdrawn Routes Length and Total Path Attribute Length fields, 3828 but talks about the value of these fields in the case of a min length 3829 UPDATE message. 3831 After Yakov's response and a posting to the list asking that this be 3832 moved to consensus, there were no objections, so this is moved to 3833 consensus. 3835 This is discussed in the "Review: Comments: Section 4.3: UPDATE min 3836 length" thread. 3838 2.60. Section 4.3 - Path Attributes 3840 Status: Consensus 3841 Change: Yes 3842 Summary: Make this change to clarify path attributes in an UPDATE: 3844 To correct the confusion I propose to replace: 3846 A variable length sequence of path attributes is present in every 3847 UPDATE. 3849 with: 3851 A variable length sequence of path attributes is present in every 3852 UPDATE message, except for an UPDATE message that carries only the 3853 withdrawn routes. 3855 Discussion: 3857 This thread began with MikeC pointing out: 3859 The top of page 13 says: 3861 "A variable length sequence of path attributes is present in every 3862 UPDATE." 3864 Is this really true, given that later, in the second to last 3865 paragraph of this section (4.3): 3867 "An UPDATE message might advertise only routes to be withdrawn from 3868 service, in which case it will not include path attributes or Network 3869 Layer Reachability Information." 3871 This could be confusing to a first time reader. 3873 The path attribute length is present in every UPDATE, the path 3874 attribute field itself can be left out, both according to the 3875 description of the minimum length of the UPDATE message and 3876 (implied?) in the picture of the UPDATE message at the beginning of 3877 section 4.3. 3879 This met with one agreement. 3881 Yakov then proposed that: 3883 To correct the confusion I propose to replace: 3885 A variable length sequence of path attributes is present in every 3886 UPDATE. 3888 with: 3890 A variable length sequence of path attributes is present in every 3891 UPDATE message, except for an UPDATE message that carries only the 3892 withdrawn routes. 3894 There was one agreement with this proposal. 3896 This is discussed in the thread: "Review: Section 4.3 - Path 3897 Attributes" 3899 2.61. Next Hop for Redistributed Routes 3901 Status: Consensus 3902 Change: Yes 3903 Summary: More clearly specify the behavior of NEXT_HOP modification, 3904 for the text see the end of the discussion. 3906 Discussion: 3908 Jonathan began this thread with: 3910 I propose adding: 3912 "When announcing a locally originated route to an internal peer, the 3913 BGP speaker should use as the NEXT_HOP the interface address of the 3914 router through which the announced network is reachable for the 3915 speaker; if the route is directly connected to the speaker, or the 3916 interface address of the router through which the announced network 3917 is reachable for the speaker is the internal peer's address, then the 3918 BGP speaker should use for the NEXT_HOP attribute its own IP address 3919 (the address of the interface that is used to reach the peer)." 3921 AFTER 3923 "When sending a message to an internal peer, the BGP speaker should 3924 not modify the NEXT_HOP attribute, unless it has been explicitly 3925 configured to announce its own IP address as the NEXT_HOP." 3927 There has been no discussion on this. 3929 This is discussed in the "Next hop for redistributed routes" thread. 3931 Issue 14 closed in favor of this issue. 3933 In response to Yakov's call for input, Michael responded that: 3935 Section 5.1.3 explicitly states what to do when originating to an 3936 external peer. #2 covers one hop away, #3 covers more than on hop 3937 away. #1 talks about sending to an iBGP peer, but only when 3938 propagating a route received from an eBGP peer. 3940 1) When sending a message to an internal peer, the BGP speaker should 3941 not modify the NEXT_HOP attribute, unless it has been explicitly 3942 configured to announce its own IP address as the NEXT_HOP. 3944 Text similar to #2 should be added, in their own bullet items to #1 3945 such as what was suggested by Jonathan Natale (text is above.) 3947 Yakov replied with this: 3949 Replace: 3951 1) When sending a message to an internal peer, the BGP speaker should 3952 not modify the NEXT_HOP attribute, unless it has been explicitly 3953 configured to announce its own IP address as the NEXT_HOP. 3955 with: 3957 1) When sending a message to an internal peer, if the route is not 3958 locally originated the BGP speaker should not modify the NEXT_HOP 3959 attribute, unless it has been explicitly configured to announce its 3960 own IP address as the NEXT_HOP. When announcing a locally originated 3961 route to an internal peer, the BGP speaker should use as the NEXT_HOP 3962 the interface address of the router through which the announced 3963 network is reachable for the speaker; if the route is directly 3964 connected to the speaker, or the interface address of the router 3965 through which the announced network is reachable for the speaker is 3966 the internal peer's address, then the BGP speaker should use for the 3967 NEXT_HOP attribute its own IP address (the address of the interface 3968 that is used to reach the peer). 3970 And stated the change would be made if there were no objections. 3971 There have been no objections, so this is at consensus. 3973 2.62. Deprecate BGP Authentication Optional Parameter from RFC1771 3975 Status: Consensus 3976 Change: Yes 3977 Summary: We are at consensus, in that we agree that we should 3978 deprecate the BGP Authentication Optional Parameter as described in 3979 RFC1771 in favor of the mechanism described in RFC2385. The textual 3980 changes are listed at the end of the discussion section of this 3981 issue. 3983 Discussion: 3985 This discussion started in issue 21: Authentication Text Update. 3987 This topic has come up before (July time frame), but was recently 3988 refreshed in the context of issue 21. It began with some questions 3989 to the list as to who used what sort of authentication mechanisms. 3990 From the responses it was clear that MD5 (RFC2385) was the preferred 3991 method. 3993 Eric Gray's message helps to flesh this out: 3995 The question is not whether MD5 authentication is used, it is how is 3996 it implemented in real BGP implementations or - more importantly - 3997 where is the authentication information located in the packets sent 3998 between two BGP peers? This is not strictly an implementation issue 3999 because authentication information is located in different places 4000 depending on which version of MD5 authentication is in use. 4002 As is generally known, options are not necessarily good. Currently, 4003 between RFC 1771 and RFC 2385, there are two very distinct ways to 4004 accomplish a semantically identical function. If the mechanism 4005 defined in RFC 1771 is not supported by a number of interoperable 4006 implementations, it must be deprecated per RFC 2026 prior to 4007 advancing the specification to Draft Standard. If it is not 4008 implemented and actually in use, it should be deprecated if for no 4009 other reason than to make the 4011 To this Yakov responded: 4013 To be more precise, 4015 In cases in which one or more options or features have not been 4016 demonstrated in at least two interoperable implementations, the 4017 specification may advance to the Draft Standard level only if those 4018 options or features are removed. 4020 So, the relevant question is whether we have at least two 4021 implementations that support authentication as described in rfc1771. 4023 Folks who implemented authentication, as described in rfc1771, please 4024 speak up. 4026 There have been no responses to Yakov's question. 4028 There seems to be a consensus that, since it is little used, and 4029 since there are better mechanisms, namely MD5 authentication, we 4030 should deprecate the BGP Authentication Optional Parameter from 4031 RFC1771. 4033 Ok, after some discussion, this is a list of the text that we are 4034 adding, changing or removing: 4036 1) Remove the reference to the authentication optional parameter: 4038 I would suggest to remove the following text from the draft: 4040 This document defines the following Optional Parameters: 4042 a) Authentication Information (Parameter Type 1): 4044 This optional parameter may be used to authenticate a BGP peer. The 4045 Parameter Value field contains a 1-octet Authentication Code followed 4046 by a variable length Authentication Data. 4048 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | Auth. Code | 4049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 4050 Authentication Data | | | 4051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4053 Authentication Code: 4055 This 1-octet unsigned integer indicates the authentication mechanism 4056 being used. Whenever an authentication mechanism is specified for 4057 use within BGP, three things must be included in the specification: 4059 - the value of the Authentication Code which indicates use of the 4060 mechanism, - the form and meaning of the Authentication Data, and - 4061 the algorithm for computing values of Marker fields. 4063 Note that a separate authentication mechanism may be used in 4064 establishing the transport level connection. 4066 Authentication Data: 4068 Authentication Data is a variable length field that is interpreted 4069 according to the value of the Authentication Code field. 4071 2) Update the introduction: 4073 In section 2 (Introduction), sixth paragraph 4075 From: 4077 BGP runs over a reliable transport protocol. This eliminates the 4078 need to implement explicit update fragmentation, retransmission, 4079 acknowledgment, and sequencing. Any authentication scheme used by 4080 the transport protocol (e.g., RFC2385 [10]) may be used in addition 4081 to BGP's own authentication mechanisms. The error notification 4082 mechanism used in BGP assumes that the transport protocol supports a 4083 "graceful" close, i.e., that all outstanding data will be delivered 4084 before the connection is closed. 4086 To: 4088 BGP uses TCP [RFC793] as its transport protocol. This eliminates the 4089 need to implement explicit update fragmentation, retransmission, 4090 acknowledgment, and sequencing. BGP listens on TCP port 179. Any 4091 authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be 4092 used. The error notification mechanism used in BGP assumes that TCP 4093 supports a "graceful" close, i.e., that all outstanding data will be 4094 delivered before the connection is closed. 4096 3) Update the message header format section: 4098 From: 4100 Marker: 4102 This 16-octet field contains a value that the receiver of the message 4103 can predict. If the Type of the message is OPEN, or if the OPEN 4104 message carries no Authentication Information (as an Optional 4105 Parameter), then the Marker must be all ones. Otherwise, the value 4106 of the marker can be predicted by some a computation specified as 4107 part of the authentication mechanism (which is specified as part of 4108 the Authentication Information) used. The Marker can be used to 4109 detect loss of synchronization between a pair of BGP peers, and to 4110 authenticate incoming BGP messages. 4112 To: 4114 Marker: 4116 This 16-octet field is included for compatibility; it must be set to 4117 all ones. 4119 4) Update the Message Header error handling section: 4121 In section 6.1 (Message Header error handling), second paragraph 4123 From: 4125 The expected value of the Marker field of the message header is all 4126 ones if the message type is OPEN. The expected value of the Marker 4127 field for all other types of BGP messages determined based on the 4128 presence of the Authentication Information Optional Parameter in the 4129 BGP OPEN message and the actual authentication mechanism (if the 4130 Authentication Information in the BGP OPEN message is present). If 4131 the Marker field of the message header is not the expected one, then 4132 a synchronization error has occurred and the Error Subcode is set to 4133 Connection Not Synchronized. 4135 To: 4137 The expected value of the Marker field of the message header is all 4138 ones. If the Marker field of the message header is not as expected, 4139 then a synchronization error has occurred and the Error Subcode is 4140 set to Connection Not Synchronized. 4142 5) Remove a paragraph from the OPEN message error handling section 4143 (section 6.2): 4145 If the OPEN message carries Authentication Information (as an 4146 Optional Parameter), then the corresponding authentication procedure 4147 is invoked. If the authentication procedure (based on Authentication 4148 Code and Authentication Data) fails, then the Error Subcode is set to 4149 Authentication Failure. 4151 6) Update the "Differences from RFC1771 Appendix" 4153 Text not listed here 4155 7) Fix the hole in the numbering by updating: 4157 From: 4159 This document defines the following Optional Parameters: 4161 a) Authentication Information (Parameter Type 1): 4163 To: 4165 This document defines the following Optional Parameters: 4167 a) Optional parameter type 1, Authentication Information, has been 4168 deprecated. 4170 We are at consensus with these changes. 4172 2.63. Clarify MED Removal Text 4174 Status: Consensus 4175 Change: Yes 4176 Summary: Modify text to clear up MED removal behavior. Text is at 4177 the end of the discussion. 4179 Discussion: 4181 This discussion began when Jonathan posted a question to the list: 4183 In reference to: 4185 "A BGP speaker MUST IMPLEMENT a mechanism based on local 4186 configuration which allows the MULTI_EXIT_DISC attribute to be 4187 removed from a route" 4189 Does anybody know how this can be done in IOS??? Looks like it 4190 cannot. 4192 Juniper??? 4194 Other code??? 4196 Change to "SHOULD"??? 4198 Enke responded that: 4200 As the MED value is treated as zero when the MED attribute is 4201 missing, removing the MED attribute is really equivalent to setting 4202 the value to zero. Based on this logic, one can argue that "MED 4203 removal" is supported by multiple vendors. 4205 However, I do see that the current text can be consolidated and 4206 cleaned up: 4208 ------------------------ 4209 5.1.4 MULTI_EXIT_DISC 4211 ... 4213 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4214 which allows the MULTI_EXIT_DISC attribute to be removed from a 4215 route. This MAY be done prior to determining the degree of 4216 preference of the route and performing route selection (decision 4217 process phases 1 and 2). 4219 An implementation MAY also (based on local configuration) alter the 4220 value of the MULTI_EXIT_DISC attribute received over an external 4221 link. If it does so, it shall do so prior to determining the degree 4222 of preference of the route and performing route selection (decision 4223 process phases 1 and 2). 4225 ------------------------- 4227 How about this: 4229 A BGP speaker MUST implement a mechanism based on local configuration 4230 which allows the value of MULTI_EXIT_DISC attribute of a received 4231 route to be altered. This shall be done prior to determining the 4232 degree of preference of the route and performing route selection 4233 (decision process phases 1 and 2). 4235 -------------------------- 4237 In responding to a question, Enke also added: 4239 > Humm. I thought with a missing MED it was preferable to be treated 4240 > as worst not as 0. 4242 It was changed a long time ago. Please see the following text in 4243 Sect. 9.1.2.2 of the draft: 4245 In the pseudo-code above, MED(n) is a function which returns the 4246 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4247 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4248 MULTI_EXIT_DISC value, i.e. 0. 4250 Curtis replied to Enke: 4252 If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a 4253 knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should 4254 change the spec to say that MED(n) returns the largest value possible 4255 is MULTI_EXIT_DISC is missing since this has better loop suppression 4256 behavior if the placement of MULTI_EXIT_DISC removal is moved in its 4257 position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out. In 4258 other words, no matter where the removal takes place, we are loop 4259 free without special rules about comparing EBGP before MED removal 4260 and then IBGP after MED removal. The only argument for MED(n) going 4261 to zero for missing MULTI_EXIT_DISC was that Cisco routers did that 4262 (and change would pose an operational issue if there wasn't a knob to 4263 facilitate the change). 4265 Note that when explicitly jamming a MULTI_EXIT_DISC value, such as 4266 zero, the issue of where in the decision process the MULTI_EXIT_DISC 4267 learned from the EBGP peers could still be used becomes a concern 4268 again. Unfortunately these implementation hints are necessary to 4269 remain loop free and so its hard to declare them out of scope, unless 4270 we forbid changing MULTI_EXIT_DISC and just allow it to be removed 4271 (which does not reflect current practice). 4273 Curtis also added: 4275 The other issue was MED handling. In "5.1.4 MULTI_EXIT_DISC": 4277 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4278 which allows the MULTI_EXIT_DISC attribute to be removed from a 4279 route. This MAY be done prior to determining the degree of 4280 preference of the route and performing route selection (decision 4281 process phases 1 and 2). 4283 An implementation MAY also (based on local configuration) alter the 4284 value of the MULTI_EXIT_DISC attribute received over an external 4285 link. If it does so, it shall do so prior to determining the degree 4286 of preference of the route and performing route selection (decision 4287 process phases 1 and 2). 4289 This doesn't sufficiently address the issue. 4291 The MED step in the decision process is (in 9.1.2.2): 4293 c) Remove from consideration routes with less-preferred 4294 MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable 4295 between routes learned from the same neighboring AS. Routes which do 4296 not have the MULTI_EXIT_DISC attribute are considered to have the 4297 lowest possible MULTI_EXIT_DISC value. 4299 This is also described in the following procedure: 4301 for m = all routes still under consideration 4302 for n = all routes still under consideration 4303 if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) 4304 remove route m from consideration 4306 In the pseudo-code above, MED(n) is a function which returns the 4307 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4308 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4309 MULTI_EXIT_DISC value, i.e. 0. 4311 Similarly, neighborAS(n) is a function which returns the neighbor AS 4312 from which the route was received. 4314 The problem is that a route loop can be formed. 4316 To avoid the route loop, two suggestions were made (2-3 years ago and 4317 nothing was done). One was to make MED(n) return infinity if there 4318 was no MULTI_EXIT_DISC. The other was to consider MULTI_EXIT_DISC in 4319 the decision process only for the purpose of selecting among the EBGP 4320 peers, then remove MULTI_EXIT_DISC, then use that best route in 4321 comparisons to IBGP learned routes. 4323 The statement in 5.1.4 "This MAY be done prior to determining the 4324 degree of preference of the route and performing route selection 4325 (decision process phases 1 and 2)" does not sufficiently address 4326 this. This implies that you MAY also remove after route selection, 4327 in which case field experience indicates you WILL get burned (unless 4328 you know about the caveat above). Initially this came up as an 4329 interoperability issue but later it was proven (in the field) that a 4330 Cisco and another Cisco could form a route loop until Cisco made this 4331 change. 4333 Additional wording is needed either in 5.1.4 or in 9.1.2.2. I 4334 suggest we put a forward reference in 5.1.4: 4336 [...]. This MAY be done prior to determining the degree of 4337 preference of the route and performing route selection (decision 4338 process phases 1 and 2). See section 9.1.2.2 for necessary restricts 4339 on this. 4341 Then in 9.1.2.2 add a clarification to the neighborAS(n) function and 4342 add to the existing text. 4344 Similarly, neighborAS(n) is a function which returns the neighbor AS 4345 from which the route was received. If the route is learned via IBGP, 4346 it is the neighbor AS from which the other IBGP speaker learned the 4347 route, not the internal AS. 4349 If a MULTI_EXIT_DISC attribute is removed before redistributing a 4350 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4351 in the comparison of EBGP learned routes, them removed, then the 4352 remaining EBGP learned route may be compared to the remaining IBGP 4353 learned routes, without considering the MULTI_EXIT_DISC attribute for 4354 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4355 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4356 learned route in the comparison with an IBGP learned route, then 4357 dropping the MULTI_EXIT_DISC and advertising the route has been 4358 proven to cause route loops. 4360 The loop is the classic I prefer your and you prefer mine problem. 4361 It occurs when the router is configured to remove MULTI_EXIT_DISC and 4362 advertise out a route so other routers can use IGP cost to select the 4363 best route. If two routers do this, as soon as they hear the route 4364 with no MULTI_EXIT_DISC from the other peer they start forwarding 4365 toward that peer but they continue to advertise to it since others 4366 IBGP peers are expected to select among the MULTI_EXIT_DISC free IBGP 4367 learned routes using the next step in the decision process, IGP cost. 4369 In this case, what you want is each router to prefer its own EBGP 4370 route, even though it has a MULTI_EXIT_DISC and the IBGP learned 4371 route from the same neighbor AS has had its MULTI_EXIT_DISC stripped 4372 off (or didn't have one, you can't tell which it is). You then want 4373 all of the IBGP peers with a MULTI_EXIT_DISC free route from that AS, 4374 or that have stripped the MULTI_EXIT_DISC to form one, to advertise 4375 them. Others in the AS will then use IGP cost to further resolve 4376 which exit point to use. It make a difference when the route is the 4377 aggregate route of another major provider. IGP cost yields what ISPs 4378 call "hot potatoe routing" and MED selects among multiple heavily 4379 loaded provider interconnects. 4381 [Aside: Having a missing MULTI_EXIT_DISC default to infinity would do 4382 exactly what the ISPs want it to do in the first place and be a lot 4383 easier to explain but we didn't fix that 2-3 years ago when the issue 4384 came up even though we had WG consensus that it was the right thing 4385 to do. The authors didn't act on it at the time (because Cisco 4386 didn't do it that way and the authors preferred to sit on the draft). 4387 At this point we might as well adequately document what we ended up 4388 with.... End of soap box. I don't take myself all that seriously so 4389 others shouldn't either. :-)] 4391 After some more discussion on this, we have this text: 4393 In 5.1.4 replace: 4395 An implementation MAY also (based on local configuration) alter the 4396 value of the MULTI_EXIT_DISC attribute received over EBGP. If it 4397 does so, it shall do so prior to determining the degree of preference 4398 of the route and performing route selection (decision process phases 4399 1 and 2). 4401 with: 4403 An implementation MAY also (based on local configuration) alter the 4404 value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY 4405 be done prior to determining the degree of preference of the route 4406 and performing route selection (decision process phases 1 and 2). 4407 See section 9.1.2.2 for necessary restricts on this. 4409 In 9.1.2.2 replace: 4411 Similarly, neighborAS(n) is a function which returns the neighbor AS 4412 from which the route was received. 4414 with: 4416 Similarly, neighborAS(n) is a function which returns the neighbor AS 4417 from which the route was received. If the route is learned via IBGP, 4418 and the other IBGP speaker didn't originate the route, it is the 4419 neighbor AS from which the other IBGP speaker learned the route. If 4420 the route is learned via IBGP, and the other IBGP speaker originated 4421 the route, it is the local AS. 4423 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 4424 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4425 in the comparison of EBGP learned routes, then removed, then the 4426 remaining EBGP learned route may be compared to the remaining IBGP 4427 learned routes, without considering the MULTI_EXIT_DISC attribute for 4428 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4429 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4430 learned route in the comparison with an IBGP learned route, then 4431 dropping the MULTI_EXIT_DISC and advertising the route has been 4432 proven to cause route loops. 4434 There have been no objections to this, so we are at consensus. 4436 2.64. MED for Originated Routes 4438 Status: Consensus 4439 Change: No 4440 Summary: The consensus is that there is not need to specify default 4441 values for MED in the base draft. 4443 Discussion: 4445 This issue began when it was pointed out that we do not specify the 4446 default values for MED in the base draft. 4448 There were a variety of responses, but the consensus is that since 4449 this is not relevant for interoperability, this does not need to be 4450 in the base spec. 4452 2.65. Rules for Aggregating with MED and NEXT_HOP 4454 Status: Consensus 4455 Change: Yes 4456 Summary: Clear up the text on aggregating with a MED. See the 4457 discussion for the text. 4459 Discussion: 4461 There is a proposal to relax this statement: 4463 "Routes that have the following attributes shall not be aggregated 4464 unless the corresponding attributes of each route are identical: 4465 MULTI_EXIT_DISC, NEXT_HOP." 4467 In his reply to the original mail, Curtis asserted that we should 4468 leave the MED rules alone, but perhaps we could relax the NEXT_HOP 4469 statement. 4471 This was revisited in the "aggregating with MED and NEXT_HOP" thread. 4473 Yakov suggested we replace: 4475 Routes that have the following attributes shall not be aggregated 4476 unless the corresponding attributes of each route are identical: 4477 MULTI_EXIT_DISC, NEXT_HOP. 4479 If the aggregation occurs as part of the update process, routes with 4480 different NEXT_HOP values can be aggregated when announced through an 4481 external BGP session. 4483 Path attributes that have different type codes can not be aggregated 4484 together. Path attributes of the same type code may be aggregated, 4485 according to the following rules: 4487 with: 4489 Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be 4490 aggregated. 4492 Path attributes that have different type codes can not be aggregated 4493 together. Path attributes of the same type code may be aggregated, 4494 according to the following rules: 4496 NEXT_HOP: When aggregating routes that have different NEXT_HOP 4497 attribute, the NEXT_HOP attribute of the aggregated route SHALL 4498 identify an interface on the router that performs the aggregation. 4500 This met with agreement. 4502 Dimitry asked if the "Routes that have different MULTI_EXIT_DESC 4503 attribute SHALL NOT be aggregated." sentence was unnecessary since it 4504 should be a matter of local policy. Jeff replied that it has been 4505 mentioned that removing this stipulation can cause routing loops. 4507 We are at consensus with this issue. 4509 2.66. Complex AS Path Aggregating 4511 Status: Consensus 4512 Change: No 4513 Summary: Since we have two implementations of this method, section 4514 6.8 stays in the specification. 4516 Discussion: 4518 Jonathan opened this discussion with: 4520 The part in the draft about complex AS path aggregation could/should 4521 be deleted. The current draft implies that when aggregating, for 4522 example (1st): 4524 1 2 4 3 4526 w/ 4528 3 4 6 5 4530 and 4532 5 6 7 8 4534 then 4536 1 2 {3 4 5 6} 7 8 4537 ...would be OK 4539 AFAIK, all implementations aggregate by either: (2nd)putting ONLY the 4540 local AS in the path (and setting the atomic) OR (3rd)by creating 1 4541 giant set and adding the local AS as a seq. 4543 So he proposed we remove this to reflect current code. 4545 Jeff replied that there is absolutely nothing wrong with doing 4546 complex aggregation, and there is no reason to remove this from the 4547 specification. 4549 Yakov responded that: 4551 Jonathan is certainly correct that the spec has to reflect current 4552 code. Therefore, unless there are at least two (interoperable) 4553 implementations that implement the algorithm described in "6.8 4554 Complex AS_PATH aggregation", this section has to be removed (this is 4555 irrespective of whether there is something wrong, or nothing wrong 4556 with complex aggregation). With this in mind, if you implement this 4557 algorithm please speak up within a week. If within a week we 4558 wouldn't know that there are at least two implementations the section 4559 will be removed. And likewise, if we hear that there are at least 4560 two implementations, the section will stay. 4562 Jeff replied: 4564 I am also fine with removing it. I just don't think its necessary, 4565 especially if One Of These Days someone decides that running policy 4566 based on as-adjacencies would be a Nice Thing and fixes their 4567 implementation to support "complex" aggregation of paths. 4569 That said, I am aware of no one who implements this. 4571 As an aside, in the thread "last thought on complex aggregation" Jeff 4572 supplied: 4574 I finally remembered what was bothering me about removing complex 4575 aggregation from the spec. 4577 If it is removed, people who do conformance tests and some 4578 implementations may take this to mean "it shall be illegal to have an 4579 AS_PATH that contains a SEQUENCE of a particular type after a SET". 4581 This would make a perfectly ok AS_PATH into one that isn't legal, 4582 even if no implementation currently generates it. 4584 Jonathan replied that he thought the issue was moot since no one has 4585 implemented this. 4587 John replied that, although he is a bit uncomfortable in removing 4588 this from the spec, he doesn't see any harm in doing so. 4590 With this in mind, Yakov suggested we consider the issue closed. 4592 So we will wait a week from 10/17 to see if anyone chimes in. 4594 Siva responded that they have implemented this functionality. So we 4595 need one more...Ben responded that they support this at Marconi as 4596 well. 4598 So we have two implementations, the section stays in the spec. We 4599 are at consensus with this issue. 4601 2.67. Counting AS_SET/AS_CONFED_* 4603 Status: Consensus 4604 Change: Yes 4605 Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to 4606 the BGP Confederations document. Update the base draft to reflect 4607 this by changing section 9.1.2.2. Specific text is at the end of the 4608 discussion. 4610 Discussion: 4612 Jonathan brought up some questions on how current implementations 4613 count AS_SET and AS_CONFED_* 4615 There were a variety of responses to this, answering his questions. 4616 Curtis pointed out that this behavior is covered in: 4618 That's in 9.1.2.2: 4620 a) Remove from consideration all routes which are not tied for having 4621 the smallest number of AS numbers present in their AS_PATH 4622 attributes. Note, that when counting this number, an AS_SET counts 4623 as 1, no matter how many ASs are in the set, and that, if the 4624 implementation supports [13], then AS numbers present in segments of 4625 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4626 count of AS numbers present in the AS_PATH. 4628 Jonathan replied that this might be at odds with what Juniper does, 4629 although he was unsure, and asked for clarification. 4631 This was discussed in the "New Issue AS path" thread. 4633 Yakov proposed that: 4635 The issue of route selection in the present of confederations belongs 4636 *not* to the base spec, but to the spec that describes BGP Confeds. 4637 With this in mind I would suggest to change in 9.1.2.2 from 4639 a) Remove from consideration all routes which are not tied for having 4640 the smallest number of AS numbers present in their AS_PATH 4641 attributes. Note, that when counting this number, an AS_SET counts 4642 as 1, no matter how many ASs are in the set, and that, if the 4643 implementation supports [13], then AS numbers present in segments of 4644 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4645 count of AS numbers present in the AS_PATH. 4647 to 4649 a) Remove from consideration all routes which are not tied for having 4650 the smallest number of AS numbers present in their AS_PATH 4651 attributes. Note, that when counting this number, an AS_SET counts 4652 as 1, no matter how many ASs are in the set. 4654 and ask the authors of BGP Confeds to update their document to cover 4655 how the presence of confeds impact route selection. 4657 This met with agreement, this issue is at consensus. 4659 2.68. Outbound Loop Detection 4661 Status: Consensus 4662 Change: No 4663 Summary: The consensus is, that while this may be a useful technique, 4664 it would break existing methods, and is otherwise out-of-scope for 4665 the base draft. It was suggested that this could be addressed in the 4666 update to RFC1772. 4668 Discussion: 4670 Jonathan brought up that: 4672 This paper (thanks Jeff) http://www.research.microsoft.com/scripts/ 4673 pubs/view.asp?TR_ID=MSR-TR-2000-08 indicates that it is better to do 4674 the loop detection outbound as well inbound. The current draft 4675 indicates that it only needs to be done inbound. IOS does it inbound 4676 as well as outbound. GateD/Juniper does it (did it ???) only 4677 inbound. 4679 So I propose we add: "An implementation MAY choose to not advertise 4680 routes to EBGP peers if these routes contain the AS of that peer in 4681 the AS path." after: "If the autonomous system number appears in the 4682 AS path the route may be stored in the Adj-RIB In, but unless the 4683 router is configured to accept routes with its own AS in the AS path, 4684 the route shall not be passed to the BGP Decision Process." 4686 *If there is at least one other implementation that does outbound 4687 pruning/loop-detection.* 4689 Yakov pointed out that this is ONLY applicable to the base draft if 4690 there are multiple implementations doing this. This issue will only 4691 be considered if these implementors come forward by 10/25/02. 4692 Otherwise the issue will be considered closed. 4694 Jeff replied that there was more at stake with this than if people 4695 had implemented it: 4697 My suggestion is that this can stay out of the base draft. While it 4698 is true that this speeds up convergence (per the paper), it doesn't 4699 affect interoperability. 4701 .in 4 Also, adding this specifically removes the ability from several 4702 implementations to be able to bridge a partitioned AS by permitting 4703 loops. (I'm not going to argue whether this is a Good way to do 4704 this, just that its done.) 4706 Its also worth noting that one could produce the same resultant 4707 speed-up by detecting the loop on an outbound basis and *not* 4708 applying the min*timers to the UPDATE. Thus, this would be a case of 4709 an advertisement of NLRI being treated the same, timer-wise, as the 4710 advertisement of WD_NLRI. 4712 I would suggest moving this suggestion for outbound loop detection in 4713 one form or another to the 1772 replacement. 4715 Yakov agreed with this. 4717 2.69. Appendix A - Other Documents 4719 Over the course of this discussion, a number of issues have been 4720 raised that the group though would be better dealt with in other 4721 documents. These additional documents, and their concomitant issues 4722 will be more fully addressed when the WG turns its focus to them. 4723 These projects are: 4725 1) Update RFC 1772: Application of the Border Gateway Protocol in the 4726 Internet. This will probably entail a complete rewrite. 4728 2) Update Route Reflector (2796) and Confederation (3065) RFC's 4729 regarding their impact on route selection. 4731 3) Write a new document covering BGP Multipath. .ne 4 4733 3. The Issues from -18 to -19 4735 This section lists the issues discussed on the list from November 4736 2002 to late February 2003. 4738 3.1. Reference to RFC 1772 4740 Status: Consensus 4741 Change: No 4742 Summary: Proposed changing RFC 1772 reference, since that document 4743 should be updated. 4745 Discussion: 4747 Jeff proposed that we reconsider referencing RFC 1772, since that 4748 document should be updated. 4750 Yakov pointed out that this is a non-normative reference and can just 4751 be left as is. 4753 Jeff agreed that this wasn't a big deal. We are at consensus to 4754 leave things as they are. 4756 This was discussed in the "-18 last call comments" thread. 4758 3.2. MUST/SHOULD Capitalization 4760 Status: Consensus 4761 Change: Yes 4762 Summary: Capitalize MUST/SHOULD where appropriate. 4764 Discussion: 4766 Jeff brought this up, and Yakov responded asking that he point out 4767 specific instances where this is needed. Jeff said he would do so, 4768 given some time. 4770 Yakov later replied that this would be fixed in the -19 version. 4772 Jeff replied with a master diff showing the MUST/SHOULDs, for the 4773 entire document please see the beginning of the thread entitled: 4774 "Issues list, #2: MUST/SHOULD Capitalization" 4775 This was discussed in the "18 last call comments" thread. This was 4776 also brought up in the "proxy: comments on draft -18" thread. 4778 3.3. Fix Update Error Subcode 7 -- accidently removed 4780 Status: Consensus 4781 Change: Yes 4782 Summary: Add error subcode 7 back in, it looks like it was 4783 inadvertently removed. Add deprecation text to Open Message Error 4784 subcode 5. 4786 Discussion: 4788 Jeff supplied: 4790 Update message error subcode 7 is removed. Especially in -18, it 4791 looks like an editing mistake based on where it would fall in the 4792 editing.. 4794 Yakov mentioned that this is addressed in Appendix A. 4796 Jeff replied: 4798 .in 4 What I would like to see is something like this: 4800 6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 - 4801 Invalid NEXT_HOP Attribute 4803 As it stands, 7 lies on a page boundary and looks like it got clipped 4804 by the roff. 4806 Yakov agreed, and also said he would add similar text for Open 4807 Message Error subcode 5. 4809 This was discussed in the "18 last call comments" thread. 4811 3.4. Section 5.1.4 - Editorial Comment 4813 Status: Consensus 4814 Change: Yes 4815 Summary: Fix "restricts" to "RESTRICTIONS" 4817 Discussion: 4819 Jeff proposed an editorial fix. This is agreed to. 4821 This was discussed in the "-18 last call comments" thread. 4823 3.5. Section 9.1 - Change "all peers" to "peers" 4825 Status: Consensus 4826 Change: Yes 4827 Summary: Section 9.1 - Change "all peers" to "peers" 4829 Discussion: 4831 Jeff proposed: 4833 .in 4 9.1: The output of the Decision Process is the set of routes 4834 that will be advertised to (delete all) peers; the selected routes 4835 will be stored in the local speaker's Adj-RIB-Out according to 4836 policy. 4838 The previous wording implied that routes in the LocRib MUST be placed 4839 in the adj-rib-out. 4841 Yakov agreed, this fix will be in the next revision. 4843 This was discussed in the "-18 last call comments" thread. 4845 3.6. AS Loop Detection & Implicit Withdraws 4847 Status: Consensus 4848 Change: Yes 4849 Summary: Update the text to reflect the AS Loop detection should be 4850 done in the BGP decision process. 4852 Discussion: 4854 John brought this up, and suggested: 4856 .in 4 I have one further comment just in case it's not perfectly 4857 obvious to everyone, which is that "ignore the UPDATE" is not 4858 strictly the action you take when receiving a looped update. Rather, 4859 you treat it as an implicit withdraw, i.e. you process it as any 4860 other update but treat the contained NLRI as unfeasible. 4862 I was going to write that this is sufficiently clear from the spec, 4863 but I regret to say that it isn't. Here is the fourth paragraph of 4864 section 9: 4866 .in 8 The information carried by the AS_PATH attribute is checked for 4867 AS loops. AS loop detection is done by scanning the full AS path (as 4868 specified in the AS_PATH attribute), and checking that the autonomous 4869 system number of the local system does not appear in the AS path. If 4870 the autonomous system number appears in the AS path the route may be 4871 stored in the Adj-RIB-In, but unless the router is configured to 4872 accept routes with its own autonomous system in the AS path, the 4873 route shall not be passed to the BGP Decision Process. Operations of 4874 a router that is configured to accept routes with its own autonomous 4875 system number in the AS path are outside the scope of this document. 4877 .in 4 I don't think this is quite right -- the decision process needs 4878 to be run if the looped routes had previously been advertised 4879 feasibly on the same session. This could be fixed by hacking the 4880 quoted paragraph, but it seems more straightforward to do it by 4881 removing the quoted paragraph and making the fix in 9.1.2 Phase 2 4882 instead. This could be done by inserting the following between the 4883 third and fourth paragraphs of 9.1.2 Phase 2: 4885 .in 8 If the AS_PATH attribute of a BGP route contains an AS loop, 4886 the BGP route should be excluded from the Phase 2 decision function. 4887 AS loop detection is done by scanning the full AS path (as specified 4888 in the AS_PATH attribute), and checking that the autonomous system 4889 number of the local system does not appear in the AS path. 4890 Operations of a router that is configured to accept routes with its 4891 own autonomous system number in the AS path are outside the scope of 4892 this document. 4894 .in 4 Section 9.3, first bullet, also addresses this topic, but I 4895 don't think it's sufficient. 4897 Yakov agreed that this was a change for the better and will include 4898 this in the next revision. 4900 We are at consensus on this issue. 4902 This is discussed in the "-18 last call comments" thread. 4904 3.7. Standardize FSM Timer Descriptions 4906 Status: Consensus 4907 Change: Yes 4908 Summary: Standardize the state descriptions on those listed in the 4909 discussion section of this issue. 4911 Discussion: 4913 Tom proposed: 4915 .in 4 I think a standard description would serve us better instead of 4916 using the following different ways (which I take all to refer to the 4917 same entity): 4919 delayBGP open timer BGP delay open timer BGP open delay timer delay 4920 open timer BGP delay timer 4922 .in 4 I suggest Open Delay timer (with those capitals) 4924 I believe that the corresponding flag is consistently referred to 4925 (apart from the capitalization) as Delay Open flag 4927 Yakov agreed with this suggestion, no one else disagreed, we are at 4928 consensus. 4930 This was discussed in the "BGP18-FSM-terminology" thread. 4932 3.8. FSM MIB enumerations 4934 Status: Consensus 4935 Change: Yes 4936 Summary: Move MIB references from the base spec into the MIB 4937 document. 4939 Discussion: 4941 Tom pointed out that: 4943 The FSM makes several references to putting values into MIB objects 4944 and while some of the values are defined, eg FSM error or Hold Timer 4945 expired, I can find no definition of the following in any of the BGP 4946 documents, MIB or otherwise. 4948 connect retry expired TCP disconnect administrative down collision 4949 detect closure Call Collision cease collision detected and dump 4950 connection Administrative stop 4952 I believe an implementation needs to be told these values somewhere 4953 and that there should be a reference to that place in bgp18. 4955 Jeff replied that to make things easier, the MIB references will be 4956 removed from the base spec, and into the MIB document. 4958 This was discussed in the "WG Last Call FSM MIB enumeration" thread, 4959 and the "bgp18 WG Last Call fsm MIB objects" thread. 4961 3.9. Make "delete routes" language consistent 4963 Status: Consensus 4964 Change: Yes 4965 Summary: Replace a variety of wording with "deletes all routes 4966 associated with this connection,". 4968 Discussion: 4970 Tom pointed out that we use a variety of language to say how we are 4971 going to delete routes in the FSM. He proposed that we instead use: 4973 - deletes all routes associated with this connection, 4975 This met with agreement, and will be reflected in the next version. 4977 This was discussed in the "bgp18 WG Last Call fsm delete action" 4978 thread. 4980 3.10. Correct OpenSent and OpenConfirm delete wording 4982 Status: Consensus 4983 Change: Yes 4984 Summary: Remove delete wording from OpenSent and OpenConfirm states. 4986 Discussion: 4988 Venu asked why there was delete wording in the OpenSent and 4989 OpenConfirm states when a BGP speaker cannot receive routes in these 4990 states. 4992 Jeff acknowledged that this was an error. Yakov agreed to fix the 4993 next version. 4995 This was discussed in the "bgp18 WG Last Call fsm delete action" 4996 thread. 4998 3.11. Incorrect next state when the delay open timer expires 5000 Status: Consensus 5001 Change: Yes 5002 Summary: Fix the next state. 5004 Discussion: 5006 Tom pointed out that: 5008 I believe that there is an incorrect next state when the delay open 5009 timer expires [event 12] in the Active state. The next state should 5010 be OpenSent and not OpenConfirm. 5012 OpenConfirm is for KeepAlive processing when Open messages have been 5013 sent and received. 5015 OpenSent is for Open sent and not yet received. 5017 The corresponding section in Connect state I believe is correct. 5019 Yakov agreed, and will fix this in the next revision. 5021 This was discussed in the "bgp18 WG Last Call fsm incorrect next 5022 state" 5024 3.12. Entering OpenConfirm / Adding "Stop OpenDelay" action 5026 Status: Consensus 5027 Change: Yes 5028 Summary: Add this text: 5030 Change 2 - Connect state event 17 (currently defined as going to 5031 Active) event 9 (stays in Connect state) 5033 new Text: 5035 In response to the connect retry timer expires event [Event 9], the 5036 local system: - drops the TCP connection, - restarts the connect 5037 retry timer, - stops the Open Delay timer and resets the timer to 5038 zero, - initiates a TCP connection to the other BGP peer, - continues 5039 to listen for a connection that may be initiated by the remote BGP 5040 peer, and - stays in Connect state. 5042 If the TCP connection fails [Event17], the local system: - restarts 5043 the connect retry timer, - stops the Open Delay timer and resets 5044 value to zero, - continues to listen for a connection that may be 5045 initiated by the remote BGP peer, and - changes its state to Active. 5047 Further discussion on Keepalives has been moved to issue 52. 5049 Discussion: 5051 This discussion began with Tom outlining these two points: 5053 When the OpenConfirm state is entered from OpenSent with the receipt 5054 of a valid open [Event 18], then a KeepAlive message is sent and the 5055 timer is started. 5057 When the OpenConfirm state is entered from Active or Connect on 5058 receipt of a valid open [Event 19], no message is sent, no timer is 5059 started. I believe this inconsistency is an error and should be 5060 corrected by adding these two actions in those two places. 5062 Sue replied: 5064 Just to clarify this comment: Event 19 = valid open with delay timer 5065 running 5067 Active = 1) awaiting TCP connection, or 2) TCP connection completed 5068 and awaiting the TCP connection with delay timer running 5070 Case 1: - should not see Event 19 In transition from Active to Open 5071 Confirm, the connection must have a TCP connection completed. Case 1 5072 does not have this occurring, so the transition must be avoided. 5074 Case 2: - should see Event 19 5076 - Open, Keepalive should be sent. 5078 Previous text: (Action H from FSM document) 5080 If an Open is received with the BGP Delay Open timer running, [Event 5081 19], the local system: - clears the connect retry timer [cleared to 5082 zero), - completes the BGP initialization, - stop and clears the BGP 5083 Open Delay timer, - Sends an Open Message, - sets the hold timer to a 5084 large value (4 minutes), and - changes its state to an Open Confirm. 5086 New text: [a New Action - N-2 : N + BGP keepalive sent] 5088 If an Open is received with the BGP Delay Open Timer running [Event 5089 19], the local system: - clear the connect retry timer [cleared to 5090 zero], - completes the BGP initialization, - stops and clears the BGP 5091 Open Delay timer, - Send an Open message, - Sends a Keepalive 5092 message, - If hold timer value is non-zero, - set keepalive timer - 5093 hold timer reset to negotiated value else if hold timer is zero, - 5094 reset the keepalive timer, and - reset the hold timer. 5096 - If the value of the autonomous system field is the same as the 5097 local Autonomous system number, set the connection status to a 5098 internal connection; otherwise it is "external". 5100 Tom and Sue discussed the OpenDelay state, and recalled that this was 5101 excluded a number of months ago as not reflecting current practice. 5103 By way of clarification, Sue added: 5105 1) Agree, this can occur in the Active state as well as the Connect 5106 state. Will you accept the earlier text below to be inserted both 5107 places? 5109 Background: 5111 The state machine for Event 19 is: 5113 Idle Connect Active Open Open Estb Sent Confirm 5114 ================================================ Event 19 | | | | | | 5115 | next state |Idle | Open | Open | Open |Idle | Idle | | | confirm| 5116 confirm| Confirm| | | 5117 ================================================ action | V | N-2 | 5118 N-2 | N | E-1 | E | ================================================ 5120 Per the State Machine. 5122 Action v - FSM Error Action E - FSM Error, drop connection - etc, 5123 drop routes Action E-1 - FSM Error, drop connection (lots of Action 5124 N-2 (text below) Action N (text below, without sending Open) 5126 2) Do you think that Event 19 is possible in the Open Sent state? 5128 Please answer this separately. 5130 Tom replied that: 5132 .in 4 1) yes I think the same text in both Active and Connect states 5133 is a good resolution 5135 2) complicated. As the fsm text stands, Event 19, along with a host 5136 of others, takes us back from Open Sent to Idle (I assume on the 5137 grounds this is an error condition) which seems very reasonable. 5139 But ...in quite a few places, such as Connect state events 2, 5140 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer 5141 when going to Idle or Active so we could then go from eg Idle with 5142 Manual start [event 1] to Connect to Open Sent all before the 5143 OpenDelay timer expires in which case event 19 can occur validly in 5144 Open Sent - obscure but possible. (This is also true with Active 5145 state and events 2, 17 and the default list at the end). 5147 But I think this is an error, and that when exiting Connect state or 5148 Active state as listed above, we should have an additional action to 5149 stop the OpenDelay timer in which case event 19 in Open Sent becomes 5150 an error condition (again). 5152 But but but as ever, I cannot speak with authority for 5153 implementations and so if implementations do not stop the OpenDelay 5154 timer when exiting as above, then Event 19 is valid in Open Sent 5155 state - obscure but possible (again). 5157 My wish is to add the extra action, stop OpenDelay timer, for the 5158 events listed above in Active and Connect states in the expectation 5159 that that is what people have or should have implemented. 5161 Tom added a response to Sue after some other threads have been 5162 discussed: .in 4 5164 You asked if event 19 (Open with OpenDelay timer running) was 5165 possible in OpenSent state; I gave a lengthy reply (below) to the 5166 effect yes it could because the OpenDelay timer did not always get 5167 stopped but the timer should be stopped in which case the event would 5168 not happen. 5170 Reading your responses to Siva , I see you include stopping the Open 5171 Delay timer in the action 'release all BGP resources' when going to 5172 Idle (which I missed seeing earlier in the year). 5174 That eliminates most but not all of the possibilities I mentioned. I 5175 now believe we would need to add the action 'stop OpenDelay timer' 5176 for Connect state event 17 (currently defined as going to Active) 5177 event 9 (stays in Connect state) 5179 in order to stop event 19 in Open Sent 5181 Sue replied that, she thought this was at consensus, and provided the 5182 new text, which is: 5184 Change 1: new text 5186 Active state - event 19 5188 If an Open is received with the Open Delay timer is running [Event 5189 19], the local system - clears the connect retry timer (cleared to 5190 zero), - stops and clears the Open Delay timer - completes the BGP 5191 initialization, - stops and clears the Open Delay timer - sends an 5192 OPEN message, - send a Keepalive message, - if the hold timer value 5193 is non-zero, - starts the keepalive timer to initial value, - resets 5194 the hold timer to the negotiated value, else if the hold timer is 5195 zero - resets the keepalive timer (set to zero), - resets the hold 5196 timer to zero. 5198 - changes its state to OpenConfirm. 5200 If the value of the autonomous system field is the same as the local 5201 Autonomous System number, set the connection status to an internal 5202 connection; otherwise it is "external". Change 2 - Connect state 5203 event 17 (currently defined as going to Active) event 9 (stays in 5204 Connect state) 5206 new Text: 5208 In response to the connect retry timer expires event [Event 9], the 5209 local system: - drops the TCP connection, - restarts the connect 5210 retry timer, - stops the Open Delay timer and resets the timer to 5211 zero, - initiates a TCP connection to the other BGP peer, - continues 5212 to listen for a connection that may be initiated by the remote BGP 5213 peer, and - stays in Connect state. If the TCP connection fails 5214 [Event17], the local system: - restarts the connect retry timer, - 5215 stops the Open Delay timer and resets value to zero, - continues to 5216 listen for a connection that may be initiated by the remote BGP peer, 5217 and - changes its state to Active. 5219 Tom replied that: 5221 .in 4 Change 2, stop Open Delay timer in Connect state events 9 and 5222 17, fine; that is what I understand to be the real issue 12. 5224 Change 1, event 19 in Active state, is IMHO issues 47 and 52. This 5225 is tangled because the initial paragraphs of Issue 12 in the issue 5226 list are nothing to to with stopping Open Delay timer and everything 5227 to to with sending a Keepalive message before entering Open Confirm 5228 state from Active or Connect state on event 19; which I raised and 5229 see as issue 52. Issue 47 was Siva's issue 28 and relates to a 5230 different action for Active state event 19. 5232 I agree with change 1 in that it adds in the sending of Keepalive 5233 which I believe essential; I think Siva needs to respond concerning 5234 issue 47. (nb the stop Open Delay action is duplicated) I wonder if 5235 we should use a different character for the bullet points under the 5236 if and else clauses to make it clear where they end ie - if the hold 5237 timer .... + do this + and this else if ... + do the other + and this 5239 But I still have an issue for Connect state event 19 where I believe, 5240 as for Active state event 19, we should send a Keepalive and start 5241 the Keepalive timer. I will pursue this as part of issue 52 if that 5242 suits you. I think the text will be the same as whatever we agree 5243 for Active state event 19. 5245 This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" 5246 thread. And also in the "Event 19 in Open Sent state was Re: bgp18 5247 WG Last Call fsm missing keepalive" thread. This also came up in the 5248 "issues 12 - consensus & two changes - 2nd message" thread. 5250 3.13. FSM Missing Next States 5252 Status: Consensus 5253 Change: Yes 5254 Summary: Seven sub-issues spawned to resolve each of the next-state 5255 questions. See each sub-issue for specifics. 5257 Discussion: 5259 This began with Tom pointing out 7 places where the next state was 5260 not clear. Interlaced with his comments below is the proposed text 5261 to fix the problems and the status of the issue. 5263 All sub-issues are at consensus. 5265 This conversation was started in the "bgp18 WG Last Call fsm missing 5266 next state" thread. 5268 3.13.1. FSM Missing Next States - Event 15 or 16 (Connect State) 5270 Status: Consensus 5271 Change: Yes 5272 Summary: Add next state of Connect. 5274 Discussion: 5276 Tom pointed out that: 5278 Connect State: 5280 If the TCP connection succeeds [Event 15 or Event 16], the local 5281 system checks the "Delay Open Flag". If the delay Open flag is set, 5282 the local system: **enters what state 5284 Sue proposed these changes: 5286 1) Connect State - Event 15 or Event 16 [consensus, editorial] 5288 note: The delay retry timer is utilized instead of the connect retry 5289 timer for the next two changes. Previous text: 5291 If the TCP connection succeeds [Event 15 or Event 16], local system 5292 checks the "Delay Open Flag". If the delay open flag is set, the 5293 local system: - clears the connect retry timer, - sets the BGP open 5294 delay timer to initial value If the Delay Open flag is not set, the 5295 local system: - clears the connect retry timer, - clear BGP Open 5296 Delay timer (set to zero), - completes the BGP initialization, - send 5297 an Open message to its peer, - sets hold timer to a large value, and 5298 - change the state to Open Sent. 5300 New text: 5302 If the TCP connection succeeds [Event 15 or Event 16], local system 5303 checks the Delay Open flag prior to processing: If the Delay Open 5304 flag is set, the local system: - clears the connect retry timer, - 5305 sets the BGP open delay timer to initial value, and - stays in the 5306 Connect state. 5308 If the Delay Open flag is not set, the local system: - clears the 5309 connect retry timer, - clears the BGP Delay timer (sets to zero), - 5310 completes the BGP initialization, - sends an Open message to its 5311 peer, - sets the hold timer to a large value, and - changes the state 5312 to Open Sent. 5314 Tom agreed that this was good, with the change to "Open Delay timer" 5315 as discussed in issue 7. 5317 This conversation was started in the "bgp18 WG Last Call fsm missing 5318 next state" thread. 5320 3.13.2. FSM Missing Next States - Event 14 (Connect State) 5322 Status: Consensus 5323 Change: Yes 5324 Summary: We selected option 2 from discussion as the correct text: 5326 2) treat it as an invalid response, reject the connection and see if 5327 a valid configured one comes within the connect timer's window. 5329 Discussion: 5331 Tom pointed out that: 5333 Connect State: 5335 If the TCP connection receives an indication that is invalid or 5336 unconfigured. [Event 14]: **enters what state 5338 Sue proposed these alternatives: 5340 2)Connect State - Event 14 [no consensus] 5342 Current Text: If the TCP connection receives an indication that that 5343 is invalid or unconfigured [Event 14], - the TCP connection is 5344 rejected. At the very least this section needs more "word smithing", 5345 so I'd like to change it for more clarity at least. 5347 I'm not sure this represents the implementations. What I'd like to 5348 do is query the implementations to see what they do if they receive a 5349 valid TCP connection with an invalid or unconfigured peer. Two 5350 options: Alternative 1: Count it as a valid response New Text: If a 5351 TCP connection is received that has an invalid format, or an 5352 unconfigured host [Event 14], the local system: - rejects the TCP 5353 connection, - increments the connect retry counter, - performs bgp 5354 peer oscillation checks. If bgp peer oscillation checks allow for a 5355 new connection, the bgp peer - restarts the Connect retry timer with 5356 configured value, and - enters the Active state. FSM table: Idle 5357 Connect Active Open-Sent Open-Confirm Establish Event-14 5358 ======================================================= Next state 5359 Idle | Active|Active|Open-Sent|Open-Confirm|Establish| 5360 ======================================================= action V | Y2 5361 | L | Ignore | Ignore | Ignore | 5362 ======================================================= Alternative 5363 2: Reject the connection and see if valid or configured one appears 5364 within the connect timer window. 5366 New Text: If a TCP connection is received that has an invalid format, 5367 or an unconfigured host [Event 14], the local system: - rejects the 5368 TCP connection, - and stays in the Connect state. 5370 FSM table: Idle Connect Active Open-Sent Open-Confirm Establish 5371 Event-14 ======================================================= Nxt 5372 state Idle |Connect|Active|Open-Sent|Open-Confirm|Establish| 5373 ======================================================= action V | L 5374 | L | Ignore | Ignore | Ignore | 5375 ======================================================= 5377 Sue then sent out a call to implementors to let the list know what 5378 they did with their FSMs. Tom replied that he agreed that we need to 5379 wait to see what the existing implementations do. He also suggested: 5381 **tp need a then clause here 'if bgp peer oscillation damping does 5382 not allow for a new connection, then the local system ???' 5384 be added before the FSM table in option 1 of the proposed text. 5386 Sue prodded the list saying that: 5388 Should the peer: 1) Treat it as a valid response, and enters the 5389 active state to watch for a another TCP connection with a valid peer. 5391 2) treat it as an invalid response, reject the connection and see if 5392 a valid configured one comes within the connect timer's window. 5394 Without further input, I will select option 2. 5396 Curtis replied that this was fine with him. 5398 There has been no further disagreement, we are at consensus on this. 5400 This conversation was started in the "bgp18 WG Last Call fsm missing 5401 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5402 input needed from developers" thread. 5404 3.13.3. FSM Missing Next States - Event 15 or 16 (Active State) 5406 Status: Consensus 5407 Change: Yes 5408 Summary: Add text listed in discussion. 5410 Discussion: 5412 Tom pointed out: 5414 Active State: 5416 A TCP connection succeeds [Event 15 or Event 16], the local system: 5417 process the TCP connection flags - If the BGP delay open flag is set: 5418 ** enters what state (I think this is an FSM error in TCP because it 5419 has not initiated a connection!) 5421 Sue proposed these changes: 5423 Previous text: A TCP connection succeeds [Event 15 or Event 16], the 5424 local system: process the TCP connection flags - If the BGP delay 5425 open flag is set: - clears the connect retry timer [through the 5426 following text: - and changes its state to Open Sent. 5428 New text: If the TCP connection succeeds [Event 15 or Event 16], 5429 local system checks the "Delay Open Flag" prior to processing: If the 5430 delay open flag is set, the local system: - clears the connect retry 5431 timer, - sets the BGP open delay timer to initial value, and - stays 5432 in the Active state. 5434 If the Delay Open flag is not set, the local system: - clears the 5435 connect retry timer, - clears the BGP Delay timer (sets to zero), - 5436 completes the BGP initialization, - sends an Open message to its 5437 peer, - sets the hold timer to a large value, and - changes the state 5438 to Open Sent. 5440 Tom agreed with this. 5442 This conversation was started in the "bgp18 WG Last Call fsm missing 5443 next state" thread. 5445 3.13.4. FSM Missing Next States - Event 13-17 (TCP Connection) 5447 Status: Consensus 5448 Change: Yes 5449 Summary: We selected: 5451 Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 be 5452 mandatory. 5454 Discussion: 5456 Tom started this by saying that: 5458 If the local system receives a valid TCP Indication [Event 13], the 5459 local system processes the TCP connection flags. ** enters what state 5461 If the local system receives a TCP indication that is invalid for 5462 this connection [Event 14]: ** enters what state 5464 Sue proposed we move this to the "fsm missing next state - Events 5465 13-17 and the TCP connection" thread. 5467 The response in this thread was: 5469 4) Active State, Event 13 [no consensus] 5) Active State, Event 14 5470 [no consensus] 5472 The problem with this state is it is difficult to exactly specify 5473 without discussing the TCP Messages that FSM document covers. I'll 5474 query if the implementors require all of events 13-17 as mandatory. 5476 Sue polled the implementors on the list with this query: 5478 These events are described in section 8.1.3. 5480 In our discussion in January through May of 2002, many implementers 5481 mapped their implementation onto the following TCP events list in 5482 8.1.3. 5484 Events 13 - 17 5486 Event 13 - TCP connection indication & valid remote peer 5488 Event 14 - TCP connection indication with invalid source or 5489 destination Event 15 - TCP connection request sent (by this peer) 5490 received an Acknowledgement 5492 [ local system sent a TCP SYN, Received a TCP SYN, ACK pair back, and 5493 Sent a TCP ACK] 5495 Event 16 - TCP connection confirmed 5497 [local system received a TCP SYN, sent a TCP SYN, ACK back, and 5498 received a TCP ACK] 5500 Event 17 - TCP connections 5502 Should we have all of these states? Which implementations support 5503 all of these Events? 5505 The full FSM text was snipped here for brevity. 5507 Sue prodded the list with: 5509 Do the implementors require Events 13 - 17 in the State machine ? 5511 Event 13 - TCP connection valid indication Event 14 - TCP connection 5512 invalid indication Event 15 - TCP connection request acknowledged 5513 Event 16 - TCP connection confirmed Event 17 - TCP connection fails 5515 Choice 1: Events 13 - 17 are mandatory Choice 2: Event 13 and Event 5516 14 be optional, and Events 15 - 17 be mandatory. If no one objects, 5517 we will use Choice 2. 5519 Curtis said this was fine with him. 5521 There has been no further disagreement, we are at consensus on this. 5522 This was started in the "bgp18 WG Last Call fsm missing next state" 5523 thread. And continued in the "fsm missing next state - Events 13-17 5524 and the TCP connection" thread. It was also discussed in the "BGP 5525 draft-19 - FSM input needed from developers" thread. 5527 3.13.5. FSM Missing Next States - Event 17 (Connect State) 5529 Status: Consensus 5530 Change: No 5531 Summary: Closed in favor of 13.4 5533 Discussion: 5535 If the local system receives a TCP connection failed [Event 17] 5536 (timeout or receives connection disconnect), the local system will: 5537 ** enters what state 5539 Sue replied with this: 5541 .in 4 comment: In the Active state, we may already have a connection 5542 and be awaiting the Open Delay timer. The TCP disconnect or timeout 5543 could occur in this state due to the "Open Delay Timer". If the TCP 5544 Disconnect is ignored, we could have some peer oscillation. 5546 If the we wait, then the connection retry timer needs to be kept 5547 running. The text below allows this timer. The real question is 5548 what is the status of the current implementations. 5550 I agree, the Active state and the connect state should match. 5552 Old Text: If the TCP connection fails (timeout or disconnection) 5553 [Event 17], the local system: - set TCP disconnect in the MIB reason 5554 code, - restart Connect retry timer (with initial value), - release 5555 all BGP resources, - Acknowledge the Drop of the TCP connection if 5556 TCP disconnect (FIN ACK), - Increment ConnectRetryCnt (connect retry 5557 count) by 1, and - performs the BGP peer oscillation damping process. 5559 Applicable FSM State table: FSM table old: Event 17 current: Idle 5560 Connect Active Open-Sent Open-Confirm Establish 5561 ========================================================= Next state 5562 Idle |Active |Idle |Active | Idle |Idle | | | | | | | 5563 ========================================================= action V | 5564 Y2 | G | Ignore| Track 2nd | Track 2nd | | | | | connection | 5565 connection| ========================================================= 5567 Alternative 1: 5569 FSM table new: 5571 Event 17 current: Idle Connect Active Open-Sent Open-Confirm 5572 Establish ========================================================= 5573 Next state Idle |Active |Active |Active | Idle |Idle | | | | | | | 5574 ========================================================= action V | 5575 G | G | Ignore| Track 2nd | Track 2nd | | | | | connection | 5576 connection| ========================================================= 5577 G: The local system: - restarts the connect retry timer (at initial 5578 value), - continues to listen for a connection that may be initiated 5579 by the remote peer, and - sets its next state to Active. 5581 New Text: (for Connect and Active state) If the TCP connection fails 5582 (timeout or disconnect) [Event 17], the local system: - restarts the 5583 connect retry timer, - continues to listen for a connection that may 5584 be initiated by the remote BGP peer, and - changes it state to 5585 Active. Alternative 2: FSM table new: Event 17 current: Idle Connect 5586 Active Open-Sent Open-Confirm Establish 5587 ========================================================= Next state 5588 Idle |Idle |Idle |Active | Idle |Idle | | | | | | | 5589 ========================================================= action V | 5590 Y2 | Y2 | Ignore| Track 2nd | Track 2nd | | | | | connection | 5591 connection| ========================================================= 5592 Next Text: If the location system receives a TCP connection failed 5593 [Event 17], the local system will: - increment the ConnectRetryCnt 5594 (connect retry count) by 1, - release all BGP resources associated 5595 with this connection, - perform BGP peer oscillation (if configured), 5596 and - go to Idle 5598 Y2 - is: The local system: 1) increments the ConnectRetryCnt (connect 5599 retry count) by 1, 2) releases all BGP resources associated with this 5600 connection, and 3) performs the BGP peer oscillation damping process 5602 if the damping process allows for a new connection, the local system: 5603 - restarts the connect retry timer (with initial value, and - goes to 5604 Idle If the damping process does not allow for a new connection, the 5605 local system - set the flags to damp the creation of a new bgp 5606 connection until a manual start occurs, and - goes to Idle. 5608 Tom agreed with the options, and stated that he preferred option 2. 5609 Sue is also happy with option 2, if no one else chimes in. 5611 After the issues list came out Tom responded to this issue, saying: 5613 .in 4 I think this issue SHOULD be administratively terminated. 5615 It relates to Connect state Event 17 (TCP connection fails) and I am 5616 credited with raising it; in fact, the issue I raised was missing 5617 next state for Active state event 17 and this has now been subsumed 5618 into 13.4 (but note that 13.4 does not explicitly say Active state - 5619 I know it should because I raised that issue too). I will ensure it 5620 does not get lost from any resolution of 13.4. 5622 And Connect state event 17 does appear as part of issue 45 which Siva 5623 raised so I think that either way, 13.5 can go. 5625 This conversation was started in the "bgp18 WG Last Call fsm missing 5626 next state" thread. 5628 3.13.6. FSM Missing Next States - Event 18 (Open Confirm) 5630 Status: Consensus 5631 Change: Yes 5632 Summary: This is the text: 5634 .in 4 In the Open Confirm state, a valid Open message [Event 22] is 5635 received. The BGP Peer connection is check to see if there is a 5636 collision per section 6.8. If this connection is to be dropped due 5637 to the call collision, the local system will drop the call by: 5639 - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to 5640 zero), - releases all BGP resources (this includes stopping the Open 5641 Delay Timer and reseting it to zero), - increments the 5642 ConnectRetryCnt by 1 (connect retry +count), and - optionally 5643 performs a BGP peer oscillation damping processing, and - enters the 5644 Idle State. 5646 Discussion: Tom opened this with: 5648 Open Confirm State: 5650 If the Open messages is valid [Event 18], the collision detect 5651 function is processed per section 6.8. If this connection is to be 5652 dropped due to call collision, the local system: ** enters what state 5654 Sue replied with: 5656 Here's my proposed text. Please let me know what you think. I think 5657 this is an editorial change. Old text: If the open message is valid, 5658 the collision detect function is processed per section 6.8. If this 5659 connection is to be dropped due to call collision, the local system: 5660 - sends a Notification with a Cease - resets the Connect timer (to 5661 zero), - releases all BGP resources, - Drop the TCP connection (sends 5662 a TCP FIN), - increments the ConnectRetryCnt by 1 (connect retry 5663 count), and - performs an BGP peer oscillation damping process. 5665 New text: If the open message is valid, the BGP peer connection is 5666 check to detect a collision per section 6.8. If this connection is 5667 to be dropped due to call collision, the local system: - sends a 5668 Notification with a Cease - resets the Connect timer (to zero), - 5669 releases all BGP resources, - Drop the TCP connection (sends a TCP 5670 FIN), - increments the ConnectRetryCnt by 1 (connect retry count), 5671 and - performs an BGP peer oscillation damping processing, and - 5672 enters the Idle State. notes: Collision detect impacts Open Sent, 5673 Open Confirm, and Established states. 5675 Tom replied: 5677 .in 4 I am still struggling with; we are in OpenConfirm so we already 5678 have received an Open from the remote peer and Event 18 is a second 5679 Open from the same peer. Perhaps my struggle is that I think in 5680 terms of two (or more) FSM for a given IP address pair so the Open 5681 Collision detection will occur when the/an- other FSM receives a 5682 valid Open in states Active/Connect/Open Sent and will generate Event 5683 22 into this FSM so Event 18 cannot occur. But yes, if Event 18 can 5684 occur in this FSM and this connection is to be dumped, then Idle 5685 state it should be as you suggest. I have slotted in [optionally] in 5686 front of the peer oscillation damping in your text because I think it 5687 should be optional:-) 5689 Sue replied: 5691 this mechanism allows a single fsm to handle both. 2 fsm and 1 fsm 5692 BGP FSM seem to exist. (I queried implementors a few times on this 5693 one. So, I just put in this change to provide the flexibility. 5695 Collision detect tends to give scrambled brains for most people.. As 5696 Dennis Ferguson said 2 years ago, that's the hardest part of the FSM. 5698 Sue then stated that she would query implementors to see what is 5699 being done. 5701 Sue prodded the list with: 5703 .in 4 In the Open Confirm state, a valid Open message [Event 22] is 5704 received. The BGP Peer connection is check to see if there is a 5705 collision per section 6.8. If this connection is to be dropped due 5706 to the call collision, the local system will drop the call by: 5708 - sending a NOTIFICATION with a CEASE, - resets the Connect timer (to 5709 zero), - releases all BGP resources (this includes stopping the Open 5710 Delay Timer and reseting it to zero), - increments the 5711 ConnectRetryCnt by 1 (connect retry +count), and - optionally 5712 performs a BGP peer oscillation damping processing, and - enters the 5713 Idle State. 5715 Implementors need to verify if this text and the text for Event 22 5716 allows all implementors to perform the necessary Call Collision 5717 actions. If no objects, we will use this text. 5719 Curtis said he had no problem with this. 5721 There has been no disagreement, we are at consensus with this. 5723 This conversation was started in the "bgp18 WG Last Call fsm missing 5724 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5725 input needed from developers" thread. 5727 3.14. FSM - Peer Oscillation Damping 5729 Status: Consensus 5730 Change: Yes 5731 Summary: Change references to peer oscillation damping to consistent 5732 phrase: 5733 "[optionally] performs peer oscillation damping". Also remove old 5734 reference to "BGP Peer Restart Backoff Mechanisms". 5736 Discussion: 5738 Tom suggested we use consistent terminology to refer to peer 5739 oscillation damping. He also pointed out a stale reference. 5741 Yakov agreed to fix both of these. 5743 3.15. FSM - Consistent FSM Event Names 5745 Status: Consensus 5746 Change: Yes 5747 Summary: Make FSM names consistent. Specifics are in the discussion 5748 section. 5750 Discussion: 5752 Tom proposed that: 5754 .in 4 The event name used in the FSM show much variation to the point 5755 sometimes where I am not clear that it is always the same event (eg 5756 where the event name is qualified by a subset of the possible 5757 causes). Assuming that it is, I propose the following changes to 5758 make the wording consistent, clear and concise for event names. 5760 ** denotes changed text using the convention /'old text'/'new text'/ 5762 8. BGP Finite State machine 5764 Event1: Manual start Event2: Manual stop Event3: Automatic start 5765 **Event4: Manual start with passive TCP /establishment/flag/ 5766 **Event5: Automatic start with passive TCP /establishment/flag/ 5767 Event6: Automatic start with bgp_stop_flap option set **Event7: 5768 Auto//matic/ stop Event8: Idle hold timer expires Event9: Connect 5769 retry timer expires **Event10: Hold time//r/ expires Event11: 5770 Keepalive timer expires Event12: Open Delay timer expires **Event13: 5771 TCP connection valid indication **Event14: TCP connection invalid 5772 indication **Event15: TCP connection request /sent received an ACK/ 5773 acknowledged/ Event16: TCP connection confirmed Event17: TCP 5774 connection fails Event18: BGPOpen Event19: BGPOpen with *Open Delay 5775 timer running Event20: BGPHeaderErr Event21: BGPOpenMsgErr Event22: 5776 Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg 5777 Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr 5779 8.2.2 Finite State Machine 5781 Connect State: 5783 If the BGP port receives a ** valid TCP connection indication [Event 5784 13], 5786 If the TCP connection receives **an invalid indication [Event 14]: 5788 If the TCP connection fails **/(timeout or disconnect)// [Event17] 5790 Active State: 5792 If the local system receives a **valid TCP //indication/ [Event 13], 5793 If the local system receives a TCP connection failed [Event 17] 5794 **/(timeout or receives connection disconnect)//, 5796 Open Sent: If a connection in Open Sent is determined to be the 5797 connection that must be closed, an **/administrative collision 5798 detect/Open collision dump/ [Event 22] is signaled to the state 5799 machine. If such an **/administrative collision detect dump [Event 5800 22]/event/ is If a TCP **//connection valid/ indication [Event 13] or 5801 TCP **//connection/ request **//acknowledged/ [Event 15] Open Confirm 5802 State: ...or receives a TCP **/Disconnect// connection fails/ [Event 5803 17] from the 5805 In the event of **/TCP establishment//TCP connection valid indication 5806 /[Event 13] 5808 ...the local system will **/issue a call/generate an Open/ collision 5809 dump [Event 22]. When the local system receives a **/call/open/ 5810 collision dump event [Event 22]/such an event/, the 5812 Established State: **/disconnect from the underlying TCP/TCP 5813 connection fails/ [Event17], it: 5815 ... it will process **/a Call/an Open/ Collision dump event[Event 5816 22]. 5818 Notes: Event 4 title brought in line with text Event 5 title brought 5819 in line with text Event 7 title brought in line with text Event 13 5820 title shortened to be closer to text, text brought in line Event 14 5821 title shortened to be closer to text, text brought in line Event 15 5822 title brought in line with text Event 17 text brought in line with 5823 title (text often introduces qualifying conditions that are too 5824 restrictive) Event 22 text brought in line with title 5826 Sue replied: 5828 I will accept the text you proposed for the Event names. I will 5829 update the FSM text to include your changes. We'll consider issue 15 5830 in consensus. I've fixed the text. 5832 So we are at consensus here. 5834 This is discussed in the thread: "bgp18 WG Last Call fsm event 5835 names." It was also discussed in the "Issue 15 - Consistent FSM 5836 Event Names" thread. 5838 3.16. Many Editorial Comments 5840 Status: Consensus 5841 Change: Yes 5842 Summary: Many editorial suggestions, and what we are doing with them 5843 are listed below. Some issues have been broken out separately where 5844 there is a longer discussion on them. 5846 Discussion: 5848 Alex began this by presenting comments from an anonymous reviewer, 5849 unless otherwise noted, responses are from Yakov: 5851 > Almost all of these are simple clarifications. > > Section 1, page 5852 5: IGP definition - it's not clear from this > definition whether 5853 IBGP would be considered an IGP? any suggestion on how to improve the 5854 definition to clarify this issue would be appreciated. 5856 There was some further discussion on this and it was decided that 5857 people reading this document ought to know what an IGP is. 5859 > Section 3, page 7, para 4: Does RFC 1772 still represent the > 5860 *planned* use of BGP? Or the actual use? Or something > different 5861 from actual use? 5863 Perhaps we should just take out references to 1772. 5865 Further discussion seemed to indicate that this reference should 5866 stay. 5868 > Section 3, page 8, para 3 - "The hosts executing..." This > 5869 paragraph seems obsolete. 5871 I'll take it out. 5873 With regard to this, Siva asked if some route optimization vendors 5874 rely on this. Since this wasn't resolved, it is discussed further in 5875 issue 17. 5877 > Section 4.1, page 11 - Length is in network byte order. 5879 all the encodings are in network byte order. This applies not just 5880 to the BGP spec, but to other protocols as well. 5882 This comment was made about a number of fields. It was later agreed 5883 that a reference would be made to this at the beginning of the 5884 document. 5886 > Section 4.2, page 12 - Hold Time - what does a value of zero > 5887 indicate? 5889 if you read section 4.4 then you'll find that: If the negotiated Hold 5890 Time interval is zero, then periodic KEEPALIVE messages MUST NOT be 5891 sent. 5893 > Section 4.2, page 13 - BGP Identifier - network byte order? > "IP 5894 address" -> "IPv4 address" 5896 I'll put at the beginning a sentence saying that in the context of 5897 this document the term "IP address" means an IP Version 4 address. 5899 > Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> > 5900 "path attributes" 5902 fixed. 5904 > Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address" > 5905 Specify that this is 4 octets. > Reference here to multi-protocol 5906 extensions for IPv6 > nexthop? 5908 no. 5910 > RFC 2283 is unclear whether NEXT_HOP should always be > included 5911 when using multiprotocol extensions. Clarify > this here? 5913 It is already clarified in 2283bis. 5915 > Section 4.3, Page 17/18 - MED and LocalPref: > "non-negative" -> 5916 "unsigned" for consistency with > elsewhere. (non-negative might 5917 - Prefix: "IP address" -> "IPv4 address" > Prefix: "enough trailing 5918 bits to" -> "the minimum number > of trailing bits needed to" 5920 fixed. 5922 > Section 4.4, Page 20: - "BGP does not use any TCP-based keep-alive 5923 > mechanism to determine if peers are reachable". Is it worth noting 5924 > that TCP may still timeout the connection even if TCP keepalives 5925 are > turned off? 5927 the text is fine as it is. 5929 > Section 4.4, Page 20: > KEEPALIVE message consists" -> "A KEEPALIVE 5930 message consists" fixed. 5932 > Section 5, Page 23: "The same attribute can not appear more than > 5933 once with the Path Attributes field...". Does this mean the same > 5934 attribute type, or the same attribute type and value? 5936 the former (the same attribute type). 5938 > Section 5.1 "The usage of each BGP path attributes .." -> > 5939 attribute 5941 fixed. 5943 > Section 5.1.3 "IP address" -> "IPv4 address" > > "A BGP speaker 5944 must never advertise an address of a peer to that > peer as a 5945 NEXT_HOP, for a route that the speaker is originating." > suggest 5946 replace this text with: > "A route originated by a BGP speaker must 5947 never be advertised to a > peer using an address of that peer as 5948 NEXT_HOP" 5950 fixed. 5952 > Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which 5953 > allows the MULTI_EXIT_DISC to be removed from a route." Might > 5954 want to say that this is dangerous unless you received the route > 5955 from an EBGP peer? 5957 think we should keep the text as is. 5959 > Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE > 5960 message that is received from an external peer, then this > attribute 5961 MUST be ignored by the receiving speaker, except for the > case of 5962 BGP Confederations [RFC3065]." > - "ignored" might be taken to mean 5963 that you don't process it for > decision, but that you propagate it 5964 to internal peers. I might > write "silently removed" or something 5965 similar. 5967 I think the text is ok as is. 5969 > Section 5.1.5, para 2. "set of AS" -> "set of ASs" 5971 fixed. 5973 > Section 6.3: wrt NEXT_HOP semantic correctness: should we check > 5974 that a NEXT_HOP is not a multicast or broadcast address? 5976 I'll add to the definition of NEXT_HOP that it is a unicast address. 5978 > Section 6.3, page 32, para 7: "peer than sent" -> "peer that > 5979 sent" 5980 fixed. 5982 > Section 6.3: "if any attribute appears more than once" - does this 5983 > mean the same attribute type, or the same attribute type and > 5984 value? 5986 the former. 5988 > Section 6.8 "Comparing BGP identifiers is done by treating them as 5989 > (4-octet-long) unsigned integers". Need to convert to host byte > 5990 order before comparing. 5992 fixed. 5994 > Section 6.8, item 2: "closes BGP connection" -> "closes the BGP > 5995 connection"; "accepts BGP connection" -> "accepts the BGP 5996 connection". 5998 fixed. 6000 > Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it 6001 > is unclear for IBGP connections how to determine "the neighbor AS > 6002 from which the other IBGP speaker learned the route". If this is > 6003 really the leftmost entry in the AS path (or the local AS if the > 6004 path is empty), the spec should explicitly say so. 6006 fixed. 6008 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6009 > attribute is removed before..." The first sentence is pretty > 6010 nearly incomprehensible. 6012 This topic has some more discussion surrounding what text we should 6013 use to clarify this issue. This is followed up in issue 18. 6015 > Section 9.1.2.2 (d) > "d) If at least one of the candidate routes 6016 was received from > an external peer in a neighboring autonomous 6017 system, remove > from consideration all routes which were received 6018 from > internal peers." > For consistency with (c) and clarity, this 6019 might be reworded: > "d) If any of the candidate routes was learned 6020 via EBGP, > remove from consideration all routes which were learned 6021 by > IBGP." 6023 fixed. 6025 > Section 9.1.2.2 (e) > "cost (n) is better than cost (m)" > Given 6026 the definition of cost, it might be clearer to say > "cost (n) is 6027 lower than cost (m)" 6028 fixed. 6030 > Section 9.1.2.2 (g) > "neighbor address" has not been defined. 6032 I'll replace "neighbor address" with "peer address". 6034 > Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes 6035 > of all routes to be aggregated should be ignored." > > Perhaps 6036 "ignored" is ambiguous here, and it's not clear > whether should is a 6037 SHOULD. Suggest: > > "Any AGGREGATOR attributes from the routes to 6038 be aggregated > MUST NOT be included in the aggregated route." fixed. 6040 > Section 9.3 - shouldn't this subsection be moved to the discussion 6041 > of Phase 1 or Phase 2 of the decision process? Or at least move it 6042 > before Section 9.2. 6044 I think it is fine where it is now. 6046 > Appendix E, para 2: IP precedence has been deprecated. Delete > 6047 this paragraph, or replace with appropriate diffserv codepoint. 6049 deleted. 6051 > Security Considerations: > "BGP supports the ability to 6052 authenticate BGP messages by using > BGP authentication." > This 6053 sentence should be removed, and the Authentication > Information 6054 parameter has been deprecated. 6056 Please see the recent e-mail exchange on the Security Considerations 6058 See issue 19 for more on the Security Considerations section of the 6059 draft. 6061 These topics were discussed in the "proxy: more comments on the draft 6062 -18" thread. 6064 3.17. Section 3, Page 8, Paragraph 3 - Obsolete? 6066 Status: Consensus 6067 Change: Yes 6068 Summary: Leave the current definition of BGP Speaker, and normalize 6069 the text to use "BGP Speaker" instead of router. 6071 Discussion: 6073 This issue was spawned from the discussions in issue 16, 6074 specifically: 6076 Anonymous reviewer: 6078 > Section 3, page 8, para 3 - "The hosts executing..." This > 6079 paragraph seems obsolete. 6081 Yakov: 6083 I'll take it out. 6085 With regard to this, Siva asked if some route optimization vendors 6086 rely on this. 6088 Jeff replied: 6090 To provide context, this paragraph currently reads: 6092 : The hosts executing BGP need not be routers. A non-routing host : 6093 could exchange routing information with routers via EGP [RFC904] : or 6094 even an interior routing protocol. That non-routing host could : 6095 then use BGP to exchange routing information with a border router : 6096 in another Autonomous System. The implications and applications of : 6097 this architecture are for further study. .in 4 There are several 6098 deployed entities that could be considered to "exploit" this 6099 paragraph. Route collectors, route servers, bandwidth shapers and 6100 other optimizers. However, the original text may be showing its age 6101 a little bit. 6103 Perhaps the following might be a bit more appropriate: 6105 "The hosts executing BGP need not be routers. A non-routing host may 6106 exchange routing information with a BGP speaker for reasons that are 6107 outside the scope of this document." 6109 I would also propose adding to the same paragraph (but could be 6110 persuaded to drop it since it is *logically* redundant): "These non- 6111 routing hosts should exercise great care not to insert themselves 6112 into the forwarding path if they re-announce BGP routes." 6114 Yakov replied: 6116 Since operations of non-routing host are outside the scope of the 6117 document, and since the document doesn't preclude non-routing hosts 6118 to run BGP, I would prefer just to take the following paragraph out, 6119 and not to add any new text. 6121 The hosts executing BGP need not be routers. A non-routing host 6122 could exchange routing information with routers via EGP [RFC904] or 6123 even an interior routing protocol. That non-routing host could then 6124 use BGP to exchange routing information with a border router in 6125 another Autonomous System. The implications and applications of this 6126 architecture are for further study. 6128 Jeff replied that this was ok, and instead suggested: 6130 At the beginning of the document, we define: BGP speaker A router 6131 that implements BGP. 6133 This (potentially) restricts a speaker to being a router. 6134 Additionally, several spots in the text where we probably should say 6135 "BGP speaker", we use router. 6137 Yakov agreed to add this definition. 6139 Jeff replied that there still was a problem with this definition 6140 being too limiting. The discussion meandered off list for a couple 6141 of exchanges and these additional definitions were proposed: 6143 First Jeff proposed this: 6145 "A router that implements the BGP protocol. Non-routing hosts that 6146 also implement BGP are out of scope of this document." 6148 Then Andrew replied, that we should make sure the definition does not 6149 opt out entirely from making sure that non-routing hosts are 6150 interoperable: 6152 BGP Speaker .in 7 A router that implements the BGP protocol. The 6153 internal behavior of non-routing hosts that also implement BGP are 6154 out of scope of this document. However, in their interactions with 6155 routers, non-routing hosts must behave as if they were routers. 6157 And Jeff replied: 6159 BGP Speaker .in 7 A router that implements the BGP protocol. The 6160 internal behavior of non-routing hosts that also implement BGP are 6161 out of scope of this document. However, in their interactions with 6162 BGP speaking routers, non-routing hosts that implement BGP should be 6163 indistinguishable from a router on the wire. .in 4 6165 (or something like that - s/on the wire/ with whatever sounds best.) 6167 IOW, look like bgp on the wire - what you do internally is out of 6168 scope. 6170 Yakov replied, that we should keep the current definition, since it 6171 is clear that non-routing hosts are outside of the scope. Jeff 6172 responded that he is ok with that if we normalize the use of "BGP 6173 Speaker" instead of "BGP router" in the document. Yakov agreed to 6174 this, we are at consensus on this. 6176 This was discussed in the "proxy: more comments on draft -18" thread. 6177 And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - 6178 Obsolete?" thread. And also, the "issue 17 - final resolution" 6179 thread. 6181 3.18. MED Removal Text 6183 Status: Consensus 6184 Change: Yes 6185 Summary: Use text at the end of the discussion. 6187 Discussion: 6189 This issue is spawned from issue 16. 6191 An anonymous reviewer pointed out: 6193 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6194 > attribute is removed before..." The first sentence is pretty 6195 nearly > incomprehensible. 6197 Yakov replied: 6199 here is my attempt to clarify this: 6201 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6202 route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 6203 attribute may only be considered in the comparison of EBGP learned 6204 routes; the attribute is then removed, and then the remaining EBGP 6205 learned routes may be compared to the remaining IBGP learned routes, 6206 without considering the MULTI_EXIT_DISC attribute for those EBGP 6207 learned routes whose MULTI_EXIT_DISC attribute will be removed before 6208 advertising these routes to IBGP. 6210 Any further suggestions on how to improve this would be appreciated. 6212 Siva replied: 6214 How about this: 6216 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6217 route into IBGP, then comparison based on the MULT_EXIT_DISC 6218 attribute may (MUST?) be performed only among the EBGP learned 6219 routes. This comparison MUST be performed before the removal of the 6220 MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then be 6221 removed from those EBGP routes where such removal is required and 6222 which are still eligible. This is followed by comparison with IBGP 6223 learned routes. 6225 I think this reflects our objectives, which is: 6227 a) If MED is to be removed, compare EBGP routes based on the MED 6229 b) Then remove the MED 6231 c) Then do comparison with IBGP routes 6233 Andrew suggested: 6235 If a router is configured to remove a MULTI_EXIT_DISC attribute from 6236 a route learned from EBGP, before re-advertising it into IBGP the 6237 router MUST compare the route with other EBGP-learned routes before 6238 removing the MULTI_EXIT_DISC. Once this comparison is complete, the 6239 MED may be removed, and any remaining routes can be compared with 6240 IBGP routes to determine the best route. 6242 Yakov replied: 6244 Here is the text that will go in the next version of the draft: 6246 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6247 route into IBGP, then comparison based on the MULT_EXIT_DISC 6248 attribute MAY be performed only among the EBGP learned routes. This 6249 comparison MUST be performed before the removal of the 6250 MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then 6251 removed from those EBGP routes where such removal is required and 6252 which are still eligible. This is followed by comparison with IBGP 6253 learned routes. 6255 Matthew responded to this with: 6257 I think this new text is ambiguous. 6259 >Here is the text that will go in the next version of the draft: > > 6260 If a MULTI_EXIT_DISC attribute is removed before re-advertising a > 6261 route into IBGP, then comparison based on the MULT_EXIT_DISC > 6262 attribute MAY be performed only among the EBGP learned routes. 6264 .in 4 This could be taken to mean either that the comparison may be 6265 performed, and if it's performed it must be performed only between 6266 EBGP learned routes, or that the comparison must be performed, but it 6267 may be performed only between EBGP learned routes. 6269 > This comparison MUST be performed before the removal of the > 6270 MULTI_EXIT_DISC attribute. 6272 .in 4 If doing the comparison is optional, then I think that this 6273 sentence should read "If the comparison is performed, then it MUST be 6274 perfo..." 6276 > The MULT_EXIT_DISC attribute is then > removed from those EBGP 6277 routes where such removal is required and > which are still eligible. 6278 This is followed by comparison with > IBGP learned routes. 6280 6282 I think that it is desirable for an operator to be able to turn off 6283 MED processing entirely (including turning off all MED based 6284 comparisons), so I would suggest the following text: 6286 .in 5 If a MULTI_EXIT_DISC attribute is removed before re-advertising 6287 a route into IBGP, comparison based on the received MULTI_EXIT_DISC 6288 attribute MAY be performed. If an implementation chooses to perform 6289 this comparison, then the comparison MUST be performed only among 6290 EBGP learned routes, and it MUST be performed before the removal of 6291 the MULTI_EXIT_DISC attribute. 6293 Curtis replied to Yakov's message: 6295 .in 4 Looks good to me. 6297 I see no need to change "This comparison MUST be performed before the 6298 removal of the MULTI_EXIT_DISC attribute". There is no implication 6299 that MULTI_EXIT_DISC must be removed and the first sentence clearly 6300 indicates that doing so is not required therefore no ambiguity. 6301 Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second 6302 sentence would be redundant. 6304 After some further discussion we have reached full consensus with: 6306 .in 4 If a MULTI_EXIT_DISC attribute is removed before re-advertising 6307 a route into IBGP, then comparison based on the received EBGP 6308 MULTI_EXIT_DISC attribute MAY still be performed. If an 6309 implementation chooses to remove MULTI_EXIT_DISC, then the optional 6310 comparison on MULTI_EXIT_DISC if performed at all MUST be performed 6311 only among EBGP learned routes. The best EBGP learned route may then 6312 be compared with IBGP learned routes after the removal of the 6313 MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a 6314 subset of EBGP learned routes and the selected "best" EBGP learned 6315 route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC 6316 must be used in the comparison with IBGP learned routes. For IBGP 6317 learned routes the MULTI_EXIT_DISC MUST be used in route comparisons 6318 which reach this step in the decision process. 6320 This is discussed in the "proxy: more comments on draft 18" thread. 6321 And in the "issue 18" thread. 6323 3.19. Security Considerations 6325 Status: Consensus 6326 Change: Yes 6327 Summary: Fix Security Considerations section to include mandatory MD5 6328 auth and advance security considerations draft along with the base 6329 draft. 6331 Discussion: 6333 Yakov started this discussion by proposing text which would require 6334 TCP MD5 authentication for BGP implementations. This is to bring the 6335 spec in line with an IETF requirement that authentication be 6336 available. 6338 After some discussion the plan is to advance 6339 draft-ietf-idr-bgp-vuln-00.txt as Informational along with the base 6340 BGP specification. This draft will serve as the security analysis 6341 section of the base spec. 6343 This is discussed in the "revised Security Considerations section" 6344 thread. 6346 3.20. Peer Oscillation Damping 6348 Status: Consensus 6349 Change: No 6350 Summary: Keep the Peer Oscillation Damping reference in the 6351 specification. 6353 Discussion: 6355 This began when Siva proposed: 6357 .in 4 Since this feature is going to be added in a new draft, and its 6358 addition will change the operation of the state machine, can we 6359 remove all mention of it in the state machine ? As part of this 6360 removal, can we also remove the IdleHold Timer from the FSM since it 6361 is not useful in the absence of peer oscillation damping ? 6363 The draft that describes this procedure can then describe the change 6364 in the state machine required to do this. 6366 Sue replied that: 6368 The reason we should not remove the peer oscillation damping from the 6369 state machine: 6371 1) Deployed implementations support peer oscillation damping 2) Hooks 6372 for the additions in the FSM cannot be added later. 6374 These hooks are optional and do not need to be implemented. 6376 Siva replied: 6378 I understand. I am not trying to object to peer oscillation damping, 6379 I think it is a good idea and we have included it in our 6380 implementation as well. I was suggesting that instead of a partial 6381 description in this draft, it be completely described in the draft on 6382 peer oscillation damping. 6384 However, I do see your point, and unless there are any objections 6385 from others, I think we have consensus on this issue. 6387 This was discussed in the "Response to FSM input - Comments 1-10" 6388 thread: Comment #1. 6390 3.21. Session Attributes - IdleHold Timer 6392 Status: Consensus 6393 Change: Yes 6394 Summary: Add the text in the discussion section. 6396 Discussion: 6398 This discussion began with Siva asking: 6400 .in 4 Why have a Hold Timer and a Hold Time ? Can we replace this 6401 with just Hold timer ? 6403 Can we also add the following session attributes: 6405 a) DelayBgpOpenTimer b) IdleHold Timer (in case we choose not to 6406 remove this from the base FSM) 6408 Can we also add the following flag to the session attributes: a) 6409 DelayOpen Flag 6411 After some discussion we have this text on the table: 6413 Event8: Idle hold timer expires 6414 Definition: An Event generated when the Idle Hold Timer expires. The 6415 Idle Hold Timer is only used when the persistent peer oscillation 6416 damping function is enabled. 6418 % Implementations not implemented persistent % peer oscillations 6419 damping functions may not % have the Idle Hold Timer. Sue replied: 6421 I will accept the new text for the following total text: Event8: Idle 6422 hold timer expires 6424 Definition: An event generated when the Idle Hold Timer .in 24 6425 expires indicating that the session has completed a back-off period 6426 to prevent bgp peer oscillation. 6428 The Idle Hold Timer is only used when the persistent peer oscillation 6429 damping function is enabled. 6431 Implementations not implementing the persistent peer oscillation 6432 damping functions may not have the Idle Hold Timer. 6434 Status: Optional 6436 We are at consensus with this. 6438 Tom added a couple of minor edits, correcting the spelling of 6439 "persistent" in the third paragraph, and pointing out that: 6441 .in 4 oscillation damping functions may not have the Idle Hold ** 6442 function ** (because we only have function not functions in the 6443 previous sentence) Timer. 6445 Sue added the edits. 6447 Siva also liked the way this issue has turned out. 6449 This was discussed in the "Response to FSM input - Comments 1-10" 6450 thread: Comment #2. And in the "Draft 19 - issue #21" thread, 6451 alternately the "Draft 19 - Issue 21" thread. 6453 3.22. Specify New Attributes (Accept Connections/Peer Oscillation 6454 Damping) 6456 Status: Consensus 6457 Change: Yes 6458 Summary: Add the text in the discussion section to section 8.0. 6460 Discussion: 6462 This began with Siva proposing: 6464 Can we call these out as well: 6466 * Accept Connections from unconfigured peers (Enabled/Disabled) * 6467 Peer Oscillation Dampening (Enabled/Disabled) (In case we choose not 6468 to remove it from base spec) 6470 After some discussion we have this text on the table: 6472 The following will be added to 8.0 Optional parameters that may be 6473 supported either per connection or per implementation: 6475 1) Delay Open flag 2) Delay Open Timer 3) Perform automatic start 6476 flag 4) Passive TCP establishment flag 5) BGP stop_peer_flag flag 6) 6477 Idle Hold timer 7) Perform automatic stop flag 8) Perform Collision 6478 detect in Establish mode flag 6480 Sue accepted these changes. 6482 Tom added this correction for item 2 in Sue's text: 6484 2) Delay Open Timer 6486 ** Open Delay timer ** (for which we have consensus in Issue list v2 6487 item 7) 6489 Siva asked, and Sue accepted these additional changes: 6491 9) accept connections from un-configured peers 5) BGP stop_peer_flap 6492 flag 6494 We are at consensus on this. 6496 This was discussed in the "Response to FSM input - Comments 1-10" 6497 thread: Comment #3. This was also discussed in the "BGP Draft 19 - 6498 Close open items 22" thread. 6500 3.23. Event1/Event2 Clean Up 6502 Status: Consensus 6503 Change: Yes 6504 Summary: Use "Local system administrator" in both sections. 6506 Discussion: 6508 Siva proposed that we clean up the text for these Events by selecting 6509 either "Administrator" or "Local system" but not both. 6511 Sue proposed text using "Local system administrator" that was agreed 6512 on. 6514 This was discussed in the "Response to FSM input - Comments 1-10" 6515 thread: Comment #4. 6517 3.24. Events 3, 5, 6 & 7 Give Examples 6519 Status: Consensus 6520 Change: No 6521 Summary: Leave the examples out. 6523 Discussion: 6525 This began with Siva proposing we add examples for these event 6526 states. Sue believes this is largely out-of-scope, but did agree to 6527 move the example of "automatic stop" to the event description 6528 section. She asked for proposed text for additional examples. 6530 Sue replied that she has made the following changes, and asked if 6531 these worked for Siva. 6533 New text: Event7: Automatic stop 6535 Definition: Local system automatically stops the BGP connection. 6537 An example of an automatic stop event is exceeding the number of 6538 prefixes for a given peer and the local system automatically 6539 disconnecting the peer. 6541 Status: Optional depending on local system 6543 Siva thought this for Event 7 was fine. 6545 Sue replied to the list, saying that, previously examples had caused 6546 dissension, and asked if there was a strong feeling either way. 6548 Siva proposed this text for Events 3, 5 & 6: 6550 Event 3: Examples of this event are: When a connection is terminated 6551 during exchange of Open messages due to version failure 6553 Event 5: Examples of this event are: Similar to Event 3 6555 Event 6: Examples of this event are: Similar to Event 3 and b) When a 6556 Idle Hold timer expires (within local limit) 6558 Sue replied to this: 6560 I'm going to leave the examples out of events 3, 4, 6 since I've not 6561 heard any strong input on the mail list **and** I had strong comments 6562 on prior versions of the draft. I'd like to declare that issue 24 6563 has consensus. 6565 Siva agreed, we are at consensus on this issue. 6567 This was discussed in the "Response to FSM input - Comments 1-10" 6568 thread: Comment #5. This was also in the "Issue 25" thread, and the 6569 "Issue 25 - this is really issue 24" threads. This is also in the 6570 "Draft 19 - Issue 24" thread. 6572 3.25. Event 4 & 5 Session Initiation Text 6574 Status: Consensus 6575 Change: No 6576 Summary: Leave the text as is. 6578 Discussion: 6580 This began with Siva wanting to change: 6582 Definition: Local system automatically starts the BGP session with 6583 the passive flag enabled. The passive flag indicates that the peer 6584 will listen prior to establishing a connection. 6586 to: 6588 The passive flag indicates that the state machine will wait for 6589 specified peer to initiate a connection with the local system. If 6590 this does not happen within a specific time (hold time), the local 6591 system will then also attempt to initiate connection with the 6592 specified peer. 6594 Sue replied: 6596 The text in 8.2.1.1 indicates the definition of the passive flag. 6a) 6597 ========== My understanding of your text is that you want to replace 6598 in both sets of text: 6600 "The passive flag indicates the peer will listen prior to 6601 establishing a connection". 6603 with: 6605 "The passive flag indicates that the state machine will wait for the 6606 specified peer to initiate a connection with a local system. 6608 The problem with this sentence is that in the "unconfigured" case the 6609 phrase "specified" peer is confusing. I think the original text is 6610 clearer. 6612 6b) ========== If this does not happen within a specific time (hold 6613 time), the local system will then also attempt to initiate (a) 6614 connection with the specified peer. My comments: Again, the 6615 "specified peer" term is confusing. Also, the 2nd half of the 6616 statement mixes the actions of the state machine with the events. I 6617 believe this muddies the text instead of clarifying it. 6619 Siva and Sue later agreed to leave the text the same because of the 6620 Unconfigured + passive TCP connection + Delay Open situation. 6622 This was discussed in the "Response to FSM input - Comments 1-10" 6623 thread: Comment #6. 6625 3.26. Event 4 & 5 - bgp_stop_flap option 6627 Status: Consensus 6628 Change: Yes 6629 Summary: Add new event below. 6631 Discussion: 6633 This began with Siva asking: 6635 Won't a variant of this with bgp_stop_flap option set be required ? 6636 We can also achieve the same by using the bgp_stop-Flap option as a 6637 flag that is provided as an input to the state machine. 6639 Siva later clarified this to include: 6641 We already have Event 3 - Automatic Start Event 5 - Automatic start 6642 with bgp_stop_flap option set To make things consistent, shouldn't we 6643 either a) Add 3 new events : .in 24 1) Manual start with bgp_stop 6644 flap option set 2) Manual start with passive TCP establishment and 6645 bgp_stop_flap option set 3) Automatic start with passive TCP 6646 establishment and bgp_stop_flap option set 6648 or b) Remove Event 6, and rely on a flag to tell us wither peer flap 6649 damping is to be performed for the session or not. 6651 Sue said she preferred option A. And stated that #1 & #2 are 6652 infeasible, but that we need to add #3. 6654 Tom replied: 6656 .in 4 But if we add an event, then we must add and agree on actions 6657 for all six existing states so I think to say that adding a new event 6658 settle things might be naive. 6660 If we do add 3) Automatic start with passive TCP establishment and 6661 bgp_stop_flap option set 6663 which I understand is Sue's resolution, then for Idle state the 6664 actions are straightforward but for the other five, is the event 6665 completely ignored? If so, does it mean that the passive flag and 6666 the bgp_stop_flap option are ignored and we carry on as if we were 6667 when we were started which may have been without them. Or is the 6668 fact of starting ignored but the flags remain set and so color the 6669 effect of other events? Needs defining. 6671 Jeff replied to this, quoting the existing draft: 6673 The start events [Event 1, 3-6] are ignored in connect state. 6675 The start events [Event1, 3-6] are ignored in the Active state. 6677 The Start events [Event1, 3-6] are ignored in the OpenSent state. 6679 Any start event [Event1, 3-6] is ignored in the OpenConfirm state. 6681 Any start event (Event 1, 3-6) is ignored in the Established state. 6683 And elaborated, saying that: 6685 .in 4 "ignore" means do nothing. This means don't twiddle with the 6686 flags. :-) 6688 The text that was finally agreed on is: 6690 Event 7: Automatic start with bgp_stop flap option set and passive 6691 TCP establishment option set Definition: Local system automatically 6692 starts the .in 24 BGP peer connection with peer oscillation damping 6693 enabled and passive TCP establishment enabled. The exact method of 6694 damping persistent peer oscillations is left up to the 6695 implementation, and is outside the scope of this document. 6697 Status: Optional, used only if the bgp peer has .in 24 enabled bgp 6698 peer oscillation damping with following optional flags settings 6699 below. 6701 Optional attributes: 1) Perform automatic start flag SHOULD be set 2) 6702 BGP stop_peer_flap flag SHOULD be set I've re-ordered the Timer 6703 events to keep the text changes down to a minimum. 6705 action 9 - connect retry timer action 10 - Hold Timer expires action 6706 11 - Keepalive timer expires action 13 - Open Delay timer expires 6707 action 14 - Idle Hold timer expires 6709 All other events are incremented by 1 6711 This was discussed in the "Response to FSM input - Comments 1-10" 6712 thread: Comment #7. 6714 3.27. Event 5 Clarification 6716 Status: Consensus 6717 Change: No 6718 Summary: Leave the text as is. 6720 Discussion: 6722 This began when Siva asked that in event 5: 6724 .in 4 Is it correct that this event will occur only when we want to 6725 restart a connection (after it had been terminated due to some reason 6726 beside administrative action) that we had accepted from an 6727 unconfigured peer ? 6729 Sue replied: 6731 .in 4 The automatic start function is an implementation specific 6732 mechanism. This text does not seek to restrict it in any fashion. 6734 Siva said that although he felt his original clarification would be 6735 more useful to new implementors he is ok with the text as is. 6737 This was discussed in the "Response to FSM input - Comments 1-10" 6738 thread: Comment #8. 6740 3.28. Timer Events Definition - Make Consistent 6742 Status: Consensus 6743 Change: Yes 6744 Summary: Change text to use "generate" across the board. 6746 Discussion: 6748 Can we use similar language for Events 8-12 to make them consistent? 6750 It was agreed that we will use "generate" i.e.: 6752 Event 8: An event generated when the Idle Hold timer expires. Event 6753 9: An event generated when the ConnectRetry timer expires. Event 10: 6754 An event generated when the Hold timer expires. Event 11: An event 6755 generated when the Keepalive timer expires Event 12: An event 6756 generated when the Delay BGP Open timer expires. This is at 6757 consensus. 6759 This was discussed in the "Response to FSM input - Comments 1-10" 6760 thread Comment #9. 6762 3.29. Event 8 - Clean Up 6764 Status: Consensus 6765 Change: Yes 6766 Summary: Clean up first sentence. New text below. 6768 Discussion: 6770 Siva began this by asking if we could clean up the wording of Event 6771 8. 6773 After some discussion with Sue we are at this change for the first 6774 sentence: 6776 An event triggered by the expiry of the Idle Hold timer, indicating 6777 that the session has completed waiting for a back-off period to 6778 prevent bgp peer oscillation. 6780 This was discussed in the "Response to FSM input - Comments 1-10" 6781 thread: Comment #10. 6783 3.30. Hold Timer - Split? 6785 Status: Consensus 6786 Change: No 6787 Summary: Keep the hold timer text as is. 6789 Discussion: 6791 Siva proposed that since: 6793 .in 4 We use the hold timer for two purposes 6795 * Waiting for an open message (with a default value of 240 seconds) * 6796 Waiting for Keepalives (with a default value of 90 seconds) 6798 Can we use two different timers (or at least call them two different 6799 timer events) ? 6800 Sue replied that this is not how it is implemented currently. Siva 6801 replied that we have two conceptually different timers, but that it 6802 would certainly work to only have one, since only one needs to be 6803 running at any given time. 6805 Tom agreed that we can keep things as is. 6807 This was discussed in the "Comments 11-20" thread: Comment #11. 6809 3.31. OpenDelay Timer Definition 6811 Status: Consensus 6812 Change: Yes - See issue 28 6813 Summary: This is fixed by the fixing of issue 28. 6815 Discussion: 6817 This began with Siva's request that we add something to Event 12 to 6818 specify what to do when the timer expires. This seems to have been 6819 addressed in issue 28. 6821 This was discussed in the "Comments 11-20" thread: Comment #12. 6823 3.32. Definition of TCP Connection Accept (Event 13) 6825 Status: Consensus 6826 Change: Yes 6827 Summary: Change "Definition" text as indicated below. 6829 Discussion: 6831 Siva proposed that we change text from referring to "TCP connection 6832 request" to "receiving a TCP connection". This led to this proposed 6833 text: 6835 Definition: Event indicating the reception of a TCP connection 6836 request with a valid source IP address and TCP port, and valid 6837 destination IP address and TCP Port. The definition of invalid 6838 source address and port and invalid destination address is left to 6839 the implementation. 6841 This met with agreement. 6843 This thread also discussed the idea of filtering the incoming 6844 address/port. It was decided that this was implementation dependent. 6846 This was discussed in the "Comments 11-20" thread: Comment #13. 6848 3.33. Event 13 & 14 - Valid Addresses & Ports 6850 Status: Consensus 6851 Change: Yes 6852 Summary: See text at the end of the discussion. 6854 Discussion: 6856 With regard to Event 13 & 14, Siva raised questions about: 1) What 6857 does it mean to validate a port, and 2) Should we state what we 6858 consider an invalid IP address to be? 6860 Sue replied that this is local policy and is implementation 6861 dependent. Siva agreed regarding the source port & IP address, but 6862 disagreed about the destination port. He argued that we need to know 6863 the destination port for interoperability. 6865 Sue asked Siva to provide some text. 6867 After a long lull, Sue replied with: 6869 I would like to keep the current text of "Should" in the following 6870 text "BGP's destination port SHOULD be port 179 as defined by IANA." 6872 Should indicates that it normally should be 179. If an 6873 implementation allows for an alternative TCP port, it is still valid 6874 as the "MUST" is not indicated. 6876 There have been no further comments on this, the chairs have decided 6877 to close it. 6879 This was discussed in the "Comments 11-20" thread: Comment #14. This 6880 was also in the "BGP-19: Issue 33" thread. 6882 3.34. Event 17 - TCP Connection Fails to TCP Connection Termination 6884 Status: Consensus 6885 Change: Yes 6886 Summary: Change the text to "fails." 6888 Discussion: 6890 This began with Siva observing: 6892 .in 4 This event can occur even when the transport connection is 6893 closed by the other end. Since this does not reflect a 'failure ', 6894 can we change the event name to 6895 % Event17: TCP connection termination 6897 Sue replied that: 6899 Discussion: It both terminates from the remote site and can "timeout" 6900 - fail. Suggestions? I can use "disconnect", what do you think. 6902 Siva replied that this was a minor issue, and on further reflection, 6903 either "fails" or "disconnect" would be acceptable. 6905 Sue replied that she has accepted Siva's comments, and the text will 6906 be changed to "fails". 6908 This was discussed in the "Comments 11-20" thread: Comment #15. This 6909 was also discussed in the "BGP-19: Issue 34-35, 40-48" thread. 6911 3.35. Making Definition Style Consistent 6913 Status: Consensus 6914 Change: Yes 6915 Summary: Adopt consistent style for the definition of events. 6917 Discussion: 6919 This started with Siva asking if we could make the definition style 6920 consistent across events. Sue replied to this with text for 13-17, 6921 Siva clarified that he was talking more about 18-21, and proposed 6922 text. 6924 We are agreed on the text for 13-17: 6926 Event13: TCP connection indication and valid remote peer 6928 Definition: Event indicating the local system reception .in 24 of a 6929 TCP connection request with a valid source IP address and TCP port, 6930 and valid destination IP address and TCP Port. The definition of 6931 invalid source, and invalid destination IP address is left to the 6932 implementation. 6934 BGP's destination port SHOULD be port 179 as defined by IANA. 6936 TCP connection request is denoted by the local system receiving a TCP 6937 SYN. 6939 Status: Mandatory (Optional) 6941 Event14: RCV TCP connection indication with invalid source or 6942 destination Definition: Event indicating the local system reception 6943 of a TCP connection request with either an invalid source address or 6944 port number or an invalid destination address or port number. BGP 6945 destination port number SHOULD be 179 as defined by IANA. 6947 Again, a TCP connection request denoted by local system receiving a 6948 TCP SYN. Status: Mandatory (Optional) Event15: TCP connection 6949 request sent received an ACK. 6951 Definition: Event indicating the Local system's request to establish 6952 a TCP connection to the remote peer. The local system's TCP session 6953 sent a TCP SYN, and received a TCP SYN, ACK pair of messages, and 6954 Sent a TCP ACK. Status: Mandatory Event16: TCP connection confirmed 6955 Definition: Event indicates that the local system receiving a 6956 confirmation that the TCP connection has been established by the 6957 remote site. 6959 The remote peer's TCP engine sent a TCP SYN. The local peer's TCP 6960 engine sent a SYN, ACK pair, and now has received a final ACK. 6961 Status: Mandatory Event17: TCP connection fails Definition: Event 6962 indicates that the local system has received a TCP connection failure 6963 notice. 6965 The remote BGP peer's TCP machine could have sent a FIN. The local 6966 peer would respond with a FIN-ACK. Another alternative is that the 6967 local peer indicated a timeout in the TCP session and downed the 6968 connection. Status: Mandatory 6970 Siva proposed these changes for 18-21: 6972 Event18: BGPOpen Definition: An event indicating that a valid Open 6973 message has been received. 6975 with Event18: BGPOpen Definition: An event is generated when a valid 6976 Open message has been received. 6978 Event19: BGPOpen with BGP Delay Open Timer running Definition: An 6979 event indicating that a valid Open message has been successful 6980 established for a peer that is currently delaying the sending of an 6981 BGP Open message. 6983 with 6985 Event19: BGPOpen with BGP Open Delay Timer running Definition: An 6986 event is generated when a valid Open message has been received for a 6987 peer that is currently delaying the sending of a BGP Open message. 6989 Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer" 6990 per issue 7. Event20: BGPHeaderErr Definition: BGP message header is 6991 not valid. 6993 with 6995 Event20: BGPHeaderErr Definition: An event is generated when a 6996 received BGP message header is not valid. 6998 Event21: BGPOpenMsgErr Definition: An BGP Open message has been 6999 received with errors. 7001 with Event21: BGPOpenMsgErr Definition: An event is generated when 7002 BGP Open message with errors has been received. 7004 Sue replied that she accepted Siva's comments, so we are at consensus 7005 here. 7007 This was discussed in the "Comments 11-20" thread: Comment #16. This 7008 also came up in the "BGP-19: Issue 34-35, 40-48" thread. 7010 3.36. Event 19 - Definition Cleanup 7012 Status: Consensus 7013 Change: Yes 7014 Summary: Replace definition for Event 19 with the text in the 7015 discussion. 7017 Discussion: 7019 Siva proposed we replace: 7021 .in 4 Definition: An event indicating that a valid Open Message has 7022 been successful established for a peer that is currently delaying the 7023 sending of an BGP Open message. 7025 with: 7027 .in 4 Definition: An event indicating that a valid OPEN Message has 7028 been received for a peer that has a successfully established 7029 transport connection and is currently delaying the sending of a BGP 7030 open message 7032 in Event 19. Sue agreed to the changes. 7034 This was discussed in the "Comments 11-20" thread: Comment #17. 7036 3.37. Event 22 - Cleanup 7038 Status: Consensus 7039 Change: Yes 7040 Summary: Replace Event 22 definition with the text from the 7041 discussion. 7043 Discussion: 7045 Siva began with observing: 7047 Event22: Open collision discard Definition: An event generated 7048 administratively when a connection Collision has been detected while 7049 processing an incoming Open message. This connection has been 7051 Isn't this event 'automatically' generated, since it is a system 7052 generated event ? 7054 Sue replied that: 7056 response: How this generated is implementation specific. The 7057 "administratively" is to cover policy. 7059 Siva also proposed an editorial fix with: 7061 Event 22 is an administrative could occur if FSM is implemented as 7062 two 7064 The word event is missing. How about 7066 Event 22 is an automatic event that could occur if FSM is implemented 7067 as two 7069 Sue replied with this rewritten text: 7071 Event22: Open collision dump Definition: An event generated 7072 administratively when a connection collision has been detected while 7073 processing an incoming OPEN message and this connection has been 7074 selected to disconnected. See Section 6.8 for more information on 7075 collision detection. 7077 Event22 is an administrative based only implementation specific 7078 policy. This Event may occur if the FSM is implemented as two linked 7079 state machines. 7081 Siva agreed with this new text. 7083 This was discussed in the "Comments 11-20" thread: Comment #18. 7085 3.38. FSM Description - ConnectRetry Count 7087 Status: Consensus 7088 Change: No 7089 Summary: Leave the counter text alone, since it is used in peer 7090 oscillation and will be in the MIB. 7092 Discussion: 7094 Siva opened with this question: 7096 The Connect Retry count is updated by the FSM but never used. In the 7097 absence of peer oscillation damping, will this be used to stop 7098 connection establishment attempts after a certain maximum number ? 7100 Yes, this is either implementation specific or is it based on 7101 the peer oscillation damping draft. 7103 Can we include the use of this counter in some place ? 7105 Connect retry counter 1) Will be utilized by the peer 7106 oscillation damping draft. 2) Will be included in bgp-4-mibv2-xx. I 7107 just check and I didn't find it. 7109 Do you still want text in the main? 7111 To which Siva replied that he believes we can leave the main text 7112 alone. 7114 This was discussed in the "Comments 11-20" thread: Comment #19. 7116 3.39. Handling Event 7 (Auto Stop) to Idle State processing 7118 Status: Consensus 7119 Change: Yes 7120 Summary: Fix the text as indicated in the discussion. 7122 Discussion: 7124 Siva began with: 7126 .in 4 The handling of Event 7 is missing from the Idle State 7127 processing. Can we add this ? How about replacing 7129 An manual stop event (Event2) is ignored in the Idle state. 7131 with 7132 Manual stop (Event 2) and Auto stop (Event 7) events are ignored in 7133 the Idle state 7135 Sue replied that she would add the text. 7137 This was discussed in the "Comments 11-20" thread: Comment #20. 7139 3.40. Clearing the Connection Retry Timer 7141 Status: Consensus 7142 Change: No 7143 Summary: Leave things alone, since it is better to be redundant than 7144 to let something slip through. 7146 Discussion: 7148 Siva opened with the observation: 7150 .in 4 There are a few sections where the FSM draft states that the 7151 Connection Retry timer needs to be reset, whereas the connect retry 7152 timer had been cleared prior to entering that state. We can remove 7153 these instructions to clear the connect retry timer. 7155 List of places where the connect retry timer need not be cleared 7157 a) Handling of Event 19 in the Connect State b) Handling of Events 12 7158 in the Active State c) All cases where it is referred to in the 7159 OpenSent, OpenConfirm and Established states 7161 Sue replied: 7163 Comment: 1) Does it hurt to have the connect retry timer cleared at 7164 these points, since it has already been cleared. 7166 I felt it eased the implementations to allow the action routines to 7167 be shared across as many states as possible. You can see this a bit 7168 more actively. 7170 Tom replied to this: 7172 .in 4 I propose we leave it in and close this issue. 7174 1) To take out an action as redundant you need to be supremely 7175 confident that it really cannot make a difference. I am not 7176 (supremely confident); rather, the more I look at the FSM, the more 7177 places I find where actions are missing, as I have posted to the 7178 list, from obscure yet possible sequences of events and timing. And 7179 there is an outstanding issue of mine which flagged seven places 7180 where the next state was missing and so I think it impossible for any 7181 one to be confident that any particular action is redundant until 7182 that is cleared up and that is proving complex in some cases. So, 7183 play safe, keep them in. 7185 2) The argument for removing them is that the number of possible 7186 distinct action lists is increased. True - it will mean that an 7187 implementor will have to code more code when first implementing BGP. 7189 For me this is no contest; keeping it safe at the possible cost of 7190 redundancy outweighs the one-off cost of additional implementation. 7192 So keep the actions in and close the issue. 7194 Jeff replied that he agreed with Tom on this. 7196 Siva concurred, that this approach was acceptable. 7198 Unless someone objects, this issue is at consensus. 7200 This was discussed in the "Comments 21-30" thread: Comment #21. This 7201 is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry 7202 timer" thread. 7204 3.41. Handling of Event 14 in the Connect State 7206 Status: Consensus 7207 Change: Yes 7208 Summary: Make event 14 optional. 7210 Discussion: 7212 Siva opened the discussion with: 7214 > If the transport connection receives an indication > that is 7215 invalid or unconfigured. [Event 14]: > - the TCP connection is 7216 rejected. 7218 I don't understand how we would get this event while in this state. 7220 Sue replied: 7222 See my earlier comments (1-10) on the connection state. It happens 7223 in implementations which track the TCP state more closely. I suggest 7224 that Event 14 become optional. 7226 Sue also suggested we fold this into the discussion about events 7227 13-17, which is tracked in issue 13.4. 7229 Sue proposed: 7231 My resolution: Let event 14 be optional. Not all BGP implementations 7232 support it. 7234 And asked if this let us reach consensus on this issue. 7236 Siva agreed with this, we are at consensus on this. 7238 This was discussed in the "Comments 21-30" thread: Comment #22. This 7239 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7241 3.42. Handling events 20, 21 in the Connect State and Active State 7243 Status: Consensus 7244 Change: Yes 7245 Summary: Use the text Tom proposed in the discussion section. 7247 Discussion: 7249 Siva began this with: 7251 We need to consider the case where we receive events 20 (message 7252 header error) and 21 (Open message error) when the delay timer is 7253 running. 7255 Since the connection has been established at this point, we need to 7256 send a Notification message and then terminate the connection. 7258 To which Sue replied: 7260 Alternative comments: 7262 1) We have not sent an Open statement. 2) Why do we have to send an 7263 Notification? I see no justification for it. 7265 Suggestion: Do you have implementations that send notification? Do 7266 you know of others that don't. 7268 Jeff saw this as indicative of an issue with section 4.2 the way it 7269 is currently written: 7271 >From section 4.2 of -18: .in 4 4.2 OPEN Message Format 7273 .in 7 After a TCP is established, the first message sent by each side 7274 is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE 7275 message confirming the OPEN is sent back. Once the OPEN is 7276 confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be 7277 exchanged. 7279 This text implies that NOTIFICATIONs can only be sent once we have 7280 sent an open and then a keepalive, generally meaning we're in the 7281 Established state. 7283 Anyone suggestions for modifying the wording? 7285 Section 6.1 (Message header error) is one situation that implies that 7286 a NOTIFICATION can be sent without sending even an OPEN message. 7287 Note that since the base FSM implies that we send an OPEN message 7288 immediately when we have a completed transport connection, we SHOULD 7289 be in at least OpenSent. However, the DelayOpen timer means that we 7290 MAY send a NOTIFICATION when we are in the Connect state. 7292 GateD, at least, will not send a NOTIFICATION without first sending 7293 an OPEN. 7295 We need to pick one: You can send NOTIFICATIONS before OPEN or before 7296 OPEN if the OpenDelay timer is running. However, we MUST fix the 7297 text above. 7299 Tom opined: 7301 .in 4 A NOTIFICATION without a preceding OPEN is rather hard to 7302 interpret; it is the OPEN that gives the recipient what it needs to 7303 know about its potential peer (Version, AS number, ID, options etc) 7304 so it makes sense to send an OPEN even if it is followed by a 7305 NOTIFICATION to say goodbye :-( as opposed to a KEEPALIVE which says 7306 hello:-). 7308 But as ever, what is implemented? 7310 Yakov suggested these modifications to the text to resolve this: 7312 .in 4 1. Delete the last sentence in the above paragraph 7314 or 7316 2. Delete "and NOTIFICATION" in the last sentence in the above 7317 paragraph 7319 Jeff replied that he preferred the first option, and that the second 7320 could be interpreted as NOTIFICATIONs not being legal, when, in fact, 7321 they may. 7323 So the text on the table to resolve this is: 7325 4.2 OPEN Message Format 7327 .in 7 After a TCP is established, the first message sent by each side 7328 is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE 7329 message confirming the OPEN is sent back. 7331 However, this does not entirely clear up the original point about the 7332 FSM. If we receive an error in Connect/Active, do we send a NOTIFY? 7333 Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in 7334 immediate succession? 7336 Sue replied: 7338 .in 4 I suggest we don't send a "NOTIFICATION" when Event 20 or Event 7339 21 is received in Connect or Active state. 7341 Tom responded to this issue with: 7343 .in 4 Issue 42 queries whether or not we can send a NOTIFICATION when 7344 we have not successfully exchanged OPENs. I propose we should, 7345 following the suggestions of Jeff and Yakov. 7347 As Yakov suggested, this requires the removal of the second sentence, 7348 first paragraph, of 4.2 which implies a NOTIFICATION can only be sent 7349 after a successful exchange of OPENs. I think this fits best with 7350 the other references to the uses of NOTIFICATION in the draft. 7352 In terms of the FSM, it means that in Connect and Active states, on 7353 receipt of events 20 or 21, we should send a NOTIFICATION so that the 7354 last section starting 7356 In response to any other event............. 7358 is replaced by (and noting we have agreed to drop references to MIB 7359 actions) 7361 If the BGP message header checking or OPEN message checking detect an 7362 error (see Section 6.2) [Events 20 or 21], the local system: - sends 7363 a NOTIFICATION message with the appropriate error code, - resets the 7364 connect retry timer (sets to zero), - releases all BGP resources, - 7365 drops the TCP connection - increments the ConnectRetryCnt (connect 7366 retry count) by 1, - [optionally] performs peer oscillation damping - 7367 and goes to the Idle state. In response to any other event (Events 7368 7-8, 10-11,18, 22-27), the local system: - resets the connect retry 7369 timer (sets to zero), - releases all BGP resources, - drops the TCP 7370 connection, - increments the ConnectRetryCnt (connect retry count) by 7371 one, - [optionally] performs peer oscillation damping, - and goes to 7372 the Idle state 7373 .in 4 (Note that this text is not quite watertight. Suppose we are 7374 in Active state, having been started with CRT running, receive an SYN 7375 (event 13), send SYN-ACK and then get a malformed message (events 7376 20/21). We have not yet received an ACK and so should not send 7377 anything over TCP; I would expect TCP to buffer this awaiting the ACK 7378 except we then take down the TCP connection - or try to; I don't know 7379 what happens next but regard it as sufficiently obscure not to be 7380 concerned). 7382 (My other concern is greater; why do we now not send NOTIFICATIONs 7383 for other events; in Open Sent, Open Confirm or Established, we send 7384 one for the 'default event list' so what makes events 20 and 21 in 7385 Active and Connect so special? I can justify the absence of a 7386 NOTIFICATION for events 7, 8, 10, 11, 18, 22 since there is no 7387 evidence of a TCP connection to send it on; but events 23-27 in 7388 Active or Connect say we have received an erroneous message, the TCP 7389 connection is there so why not send a NOTIFICATION? Event7: 7390 Automatic stop Event8: Idle hold timer expires Event10: Hold timer 7391 expires Event11: Keepalive timer expires Event18: BGPOpen Event22: 7392 Open collision dump Event23: NotifMsgVerErr Event24: NotifMsg 7393 Event25: KeepAliveMsg Event26: UpdateMsg Event27: UpdateMsgErr 7395 Sue accepted Tom's text, so barring any objections, we are at 7396 consensus on this. 7398 This was discussed in the "Comments 21-30" thread: Comment #23. This 7399 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and 7400 the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread. 7402 3.43. Handling the default events in the Connect state 7404 Status: No Consensus 7405 Change: Potentially 7406 Summary: Add text at the end of the discussion. 7408 Discussion: 7410 Siva opened this with: 7412 .in 4 The Open Delay timer [original: BGP Delay Open Timers) needs to 7413 be cleared if it is running. 7415 How about adding this: 7417 % - If the ConnectRetry Timer is running % - Clear the Connect Retry 7418 timer % - Otherwise % - Clear the Open Delay timer [original: BGP 7419 Delay Open Timer] 7420 Sue replied that: 7422 By the default you mean the text: 7424 In response to any other events[Events 7-8, 10-11, 18, 20-27], the 7425 local system: 7427 "resets" to me implies stops and clears. I think the text is clear 7428 than the text above. ------------ Is this the replacement text you 7429 imply above: - resets the connect retry timer (sets to zero), - 7430 clears the Open Delay timer [original: BGP Delay timer] (sets to 7431 zero), - increments the ConnectRetryCnt (connect retry count) by 1, - 7432 [optionally] performs bgp peer oscillation damping, and - goes to 7433 Idle text: 7435 Editor's note: various incarnations of "Open Delay timer" have been 7436 replaced with "Open Delay timer". See issue 7. 7438 Sue replied that she accepted Siva's changes with these editorial 7439 changes: 7441 old text: - resets the connect retry timer (sets to zero) - clears 7442 the open delay timer 7444 new text: - if the connect retry timer is running, clear the connect 7445 retry timer (set to zero). - if the open delay timer is running, 7446 clear the open delay timer (set to zero). 7448 Since the substantive changes have been accepted, unless someone 7449 objects, this issue is at consensus. 7451 This was discussed in the "Comments 21-30" thread: Comment #24. This 7452 was also brought up in the "BGP-19: Issue 34-35, 40-48" 7454 3.44. Handling Event 23 in Connect and OpenSent 7456 Status: Consensus 7457 Change: Yes 7458 Summary: Adopt text at the end of the discussion section. 7460 Discussion: 7462 This began with Siva saying: 7464 .in 4 This is currently being handled in the default event processing 7465 section. However, we do not need to go through the peer oscillation 7466 damping process in this case. Can we change the wordings to reflect 7467 this, or move this out of peer oscillation damping processing ? 7468 Sue replied: 7470 1) There is no default event handling process in the text, you will 7471 need to specify the text. 7473 2) The state table below (hares-statemt-03.txt) states shows the 7474 changes 7476 ------------- 7477 Event 23 7478 states: 7479 current Idle Connect Active Open-Sent Open-Cnf Establish 7480 ------------------------------------------------- 7481 next state Idle Idle Idle Idle Idle Idle 7482 ------------------------------------------------- 7483 action V D D Y Y T ================================================= 7485 V - Indicate FSM errors and ignore. D - 1) resets the connect retry 7486 timer (sets to zero), 2) drops the TCP connection, 2) releases all 7487 BGP resources, 3) increments the ConnectRetryCnt (connect retry 7488 count) by 1, 4) [optionally] performs the bgp peer oscillation 7489 damping, and Goes to Idle state. Y 1) resets the connect retry timer 7490 (sets to zero), 2) Drops the TCP connection, 3) releases all BGP 7491 resources, 4) [optionally] 7493 In an exchange between Siva and Sue, this came up: 7495 Siva: 7497 "Default event handling" was perhaps a poor choice of words. 7499 What I meant is this 7501 .in 4 Event 23 (Notify Message Version error) only indicates a 7502 version mismatch. By going through action sequence D, we will be 7503 performing peer oscillation damping. Should we perform damping, 7504 since this is not really a cause for persistent oscillation ? 7506 Also, since we have a distinct event to indicate a version error 7507 event, can include text indicating that version negotiation 7508 processing should take place upon receipt of this event ? 7510 Sue: 7512 Yes, we can change the "D" in state machine to a "y". 7514 The issue is what if Connect state occurs and there is not a TCP 7515 connection. Should an OPEN with wrong version be accepted? If the 7516 Open Delay flag is off, the connection state should not be getting an 7517 Open. The "D" action below works for "open delay flag off". 7519 The "y" action you suggest can occur if the open delay timer is on. 7521 If this is the issue, please confirm. 7523 We could say: if open delay flag is on -> y action if open delay flag 7524 is off -> D action 7526 Please let me know if this is the concern, and suggest text. 7528 Prior to this exchange, this issue was at consensus. The only thing 7529 that is firm in this exchange is changing "D" to "y". There seems to 7530 be some open discussion still, so we'll reopen it. 7532 After some discussion, this is the text we have settled on: 7534 If a NOTIFICATION message is received with a version error[Event24], 7535 the local system checks the Open Delay timer. If the Open Delay 7536 timer is running, the local system: - resets the connect retry timer 7537 (sets to zero), - stops and reset the Open Delay timer (sets to zero, 7538 - releases all BGP resources, - drops the TCP connection, - changes 7539 its state to Idle. If the Open Delay timer is not running, the local 7540 system: - resets the connect retry timer (sets to zero), - releases 7541 all BGP resources, - drops the TCP connection, - increments the 7542 ConnectRetryCnt (connect retry count) by 1, - optionally performs 7543 peer oscillation damping, and - changes its state to Idle. 7545 N.B. This is now event 24 (see issue 26). 7547 We are at consensus with this. 7549 This was discussed in the "Comments 21-30" thread: Comment #25. This 7550 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7552 3.45. Event 17 in the Connect state 7554 Status: Consensus 7555 Change: Yes 7556 Summary: Adopt text at the end of the discussion section. 7558 Discussion: 7560 This began with Siva asking: 7562 .in 4 If the transport connection fails (timeout or transport 7563 disconnect) [Event17], the local system: - changes its state to 7564 Active. 7566 If the transport connection fails when the Open Delay timer 7567 [original: BGP Open Delay timer] is running, should we still be going 7568 into the Active state ? 7570 Sue replied referring to the discussion tracked in issue 13.4. 7572 Jeff responded that: 7574 .in 4 In this particular case, I think the issue is separate from the 7575 issues for events 13-17 since this isn't particular to how deep the 7576 BGP implementation meddles in the TCP implementation. 7578 If we are in the Connect state, because we have an incoming transport 7579 connection that has completed, but we have the OpenDelay timer 7580 running and the transport connection is closed, we can simply drop 7581 into Active after resetting the ConnectRetry timer and clearing the 7582 OpenDelay timer (if set/exists). In the case of an unconfigured 7583 peer, we can discard the FSM instance. 7585 Tom replied that he agreed with this. 7587 Tom then proposed this text: 7589 If the TCP connection fails[Event 17] and the Open Delay timer is 7590 running, the local system: - restarts the connect retry timer, - 7591 clears the Open Delay timer - continues to listen for a connection 7592 that may be initiated by the remote BGP peer, and - changes its state 7593 to Active. 7595 If the TCP connection fails [Event17] and the Open Delay timer is not 7596 running, the local system: - drops the TCP connection, - releases all 7597 BGP resources, - sets ConnectRetryCnt (the connect retry count) to 7598 zero - resets the connect retry timer (sets to zero), and - goes to 7599 Idle state. 7601 to replace If the TCP connection fails (timeout or disconnect) 7602 [Event17], the local system: - restarts the connect retry timer, - 7603 continues to listen for a connection that may be initiated by the 7604 remote BGP peer, and - changes its state to Active. 7606 Sue agreed to change the text to reflect the comments. 7608 Jeff brought out a couple of other concerns, and Tom replied: 7610 > If the TCP connection fails [Event17] and the Open Delay > timer is 7611 not running, the local system: > - drops the TCP connection, > - 7612 releases all BGP resources, 7614 .in 4 There are no resources to release while in the connect state. 7615 (Unless we're using this as shorthand for something else - I forget.) 7617 Tom: 7619 .in 4 I was unsure about this action. It is present for Active state 7620 event 17 which is why I put it in, it does include sub-actions such 7621 as clear Open Delay timer (not running), clear Connect Retry timer 7622 (could be running) so I think it right to play safe and include it. 7624 Jeff: 7626 > - sets ConnectRetryCnt (the connect retry count) to zero 7628 I'm forgetting if this action is consistent with everything else. I 7629 don't have a current copy of the FSM and I don't trust -18 to be 7630 current enough. :-) This said, why do we go to zero? I could see not 7631 incrementing it and letting the normal decay process deal with it. 7632 The same would apply for the above. 7634 Tom: 7636 .in 4 Again, I was unsure about this so put it in and waited for 7637 comment. I have a chart of 27 events and 6 states in which I have 7638 colored in the connect retry and peer oscillation damping actions and 7639 it looks like measles; I could not divine the underlying logic. 7640 Incrementing the connect retry count would make as much if not more 7641 sense to me. (It is zeroed for Manual Stop). 7643 But the action '[optionally] perform peer oscillation damping' is yet 7644 more erratic (eg for event 10 - Hold Timer expired - it is performed 7645 exiting Connect, Active, Established but not Open Confirm or Open 7646 Sent) so I left it out. Again, it might make more sense put it in. 7648 Sue replied to this: 7650 The connect state could have a few resources (minimum peer footprint) 7651 as the FSM goes from Idle to Connected state. While this amount of 7652 BGP resources is not as much as the final amount, it still needs to 7653 get released. 7655 2nd - I think the ConnectRetry count should be removed; Thanks for 7656 catching that. 7658 Please confirm that part #1 is OK with you so we can put issue 45 7659 into consensus state. 7661 Sue accepted Tom's solution, for the following text: 7663 If the TCP connection fails [Event18], the local system checks the 7664 Open Delay Timer. If the Open Delay timer is running, the local 7665 system: - restarts the connect retry timer, - stops the Open Delay 7666 timer and resets value to zero, - continues to listen for a 7667 connection that may be initiated by the remote BGP peer, and - 7668 changes its state to Active. If the open Delay timer is not running, 7669 the local system: - resets the connect retry timer (sets to zero), 7670 and - Drops the TCP connection, - Releases all BGP resources, - and 7671 goes to Idle State. 7673 N.B. This is now event 18 (see issue 26). 7675 We are at consensus with this. 7677 This was discussed in the "Comments 21-30" thread: Comment #26. This 7678 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7680 3.46. Handling of Event 17 in Active state 7682 Status: Consensus 7683 Change: No 7684 Summary: See issue 13.4, this issue closed in favor of that one. 7686 Discussion: 7688 This began with Siva saying: 7690 We should now move into Idle state. Can we add 7692 % - Goes to Idle state 7694 Sue replied that she thought this should be bundled in with the issue 7695 tracked in 13.4. Since no one objected, this issue has been closed 7696 in favor of that one. 7698 This was discussed in the "Comments 21-30" thread: Comment #27. 7700 3.47. Handling of Event 19 in Active state 7702 Status: Consensus 7703 Change: Yes 7704 Summary: Add the new text in the discussion section. 7706 Discussion: 7708 This began with Siva suggesting: 7710 > - Set the Hold timer to a large value (4 minutes), Since OPEN 7711 messages have been exchanged, can we change this to - If the 7712 negotiated Hold time is not 0, set the Hold time to - the negotiated 7713 value 7715 Sue replied that: 7717 The text in Active and Open Sent needs to be the same. The text in 7718 Open Sent is: - sets the Hold timer according to the negotiated value 7719 (see section 4.2), and 7721 Which text do you prefer? 7723 Sue replied that this text would be added to the next draft: 7725 New text 7727 - if the hold timer value is non-zero, - starts the keepalive timer 7728 to initial value, - resets the hold timer to the negotiated value, - 7729 else if the hold timer is zero - resets the keepalive timer (set to 7730 zero), - resets the hold timer to zero. 7732 This seems to address Siva's concerns, this issue is at consensus, if 7733 there are objections, we can reopen it. 7735 This was discussed in the "Comments 21-30" thread: Comment #28. This 7736 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7738 3.48. Handling of Event 2 in Active state 7740 Status: Consensus 7741 Change: Yes 7742 Summary: Update the draft with the text at the end of the discussion 7743 section. 7745 Discussion: 7747 Siva opened with: 7749 > A manual stop event[Event2], the local system: > - Sends a 7750 notification with a Cease, > - drops the Transport connection 7752 These two actions are possible only if a transport connection had 7753 already been established. How about changing the text to 7755 % - If a transport connection had been successfully established % - 7756 Send a Notification with a Cease % - Drop the Transport Connection 7757 Sue counter suggested: 7759 A manual stop event [Event 2], the local system - Drop the TCP 7760 connection, - Release all BGP resources, - resets the connection 7761 retry timer [sets to zero], - goes to Idle. 7763 Jeff replied: 7765 I'm rather confused. Under exactly what circumstances can we be in 7766 the Active state and have an active TCP connection at all? Ditto for 7767 having any BGP resources? 7769 Going to Idle is fine. 7771 Tom offered this example: 7773 eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK 7774 received, Delay Open flag set and there we are. Most events are now 7775 possible either from a well-implemented remote peer or a badly 7776 implemented remote peer. 7778 Sue asked if there were any additional comments, if not, the text 7779 will be: 7781 A manual stop event[Event2], the local system: - Sends a NOTIFICATION 7782 with a Cease, - releases all BGP resources including - stopping the 7783 Open delay timer - drops the TCP connection, - sets ConnectRetryCnt 7784 (connect retry count) to zero - resets the connect retry timer (sets 7785 to zero), - changes its state to Idle. 7787 There have been no additional comments, we will use the text Sue 7788 proposed. 7790 This was discussed in the "Comments 21-30" thread: Comment #29. This 7791 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7793 3.49. Default Event handling in Active state 7795 Status: Consensus 7796 Change: No 7797 Summary: No routes in active. 7799 Discussion: 7801 Siva began with: 7803 To ensure consistency with E2 handling, can we add 7804 % - If any BGP Routes exist, delete the routes 7806 Sue replied: 7808 Comment: Yakov and Jeff noted, there are no routes in Active state. 7810 Since there were no responses disagreeing, we'll consider this closed 7811 unless someone wants to open it back up. 7813 This was discussed in the "Comments 21-30" thread: Comment #30. 7815 3.50. Clearing Hold timer in OpenSent, OpenConfirm and Established 7816 State 7818 Status: Consensus 7819 Change: No 7820 Summary: This issue is addressed in the "Clear BGP resources" 7822 Discussion: 7824 This began with Siva stating: 7826 .in 4 In all event handling where we go to Idle state, we need to 7827 clear the Hold Timer as well. 7829 Sue replied that: 7831 issue resolve one way last Jan - March Clearing of keep alive timer 7832 included in Clear BGP resources 7834 No response to this yet, but since this seems to be resolved it is at 7835 consensus unless someone objects. 7837 This was discussed in the "Comments 30-36" thread: Comment #31. 7839 3.51. Clearing Keepalive timer in OpenConfirm and Established State 7841 Status: Consensus 7842 Change: No 7843 Summary: This issue is addressed in the "Clear BGP resources" 7845 Discussion: 7847 This began with Siva stating: 7849 .in 4 In all event handling where we go to Idle state, we need to 7850 clear the Keepalive Timer as well. 7852 Sue replied that: 7854 issue resolve one way last Jan - March Clearing of keep alive timer 7855 included in Clear BGP resources 7857 No response to this yet, but since this seems to be resolved it is at 7858 consensus unless someone objects. 7860 This was discussed in the "Comments 30-36" thread: Comment #32. 7862 3.52. Handling Event 18 in the OpenSent state (Keepalive Timer) 7864 Status: Consensus 7865 Change: Yes 7866 Summary: Make the event optional. 7868 Discussion: 7870 This began with Siva asking: 7872 .in 4 Why do we start the Keepalive timer at this stage ? Isn't it 7873 sufficient to do so when we move into Established state ? 7875 Sue replied: 7877 An earlier comment from Tom (and you) requested the following: 7879 <--Open [Open sent state] 7881 Open--> [Event 18] 7883 <---Open <---Keepalive [Action from Event 18 in Open Sent] [Open 7884 Confirm] Keepalive -> [Event 25] [established] 7886 What do implementations do? We'll have to query implementations. 7888 Jeff added: 7890 I'm assuming the second OPEN going from right to left is a typo. If 7891 it isn't, thats a FSM error to the peer on the left. 7893 Theoretically, an implementation that utilizes its keepalive timer to 7894 send the first keepalive to transition to Established is still 7895 interoperable. However: 7897 o Keepalives can be disabled by negotiating hold time of zero o We 7898 really shouldn't need to restart the Keepalive timer. If there is a 7899 delay in the keepalive that transitions from OpenConfirm to 7900 Established, its due to the transport connection. It should be 7901 reliable and it *should* get through. If it doesn't, there's other 7902 problems and the hold timer for the peer on the right should do the 7903 Right Thing and drop the connection. 7905 > What do implementations do? We'll have to query implementations. 7907 .in 4 GateD at least waits to enter the Established state prior to 7908 starting the KeepAlive timer. 7910 Tom also added: 7912 .in 4 My comment was that if we do not send a KeepAlive (and start 7913 the KeepAlive timer), on exiting from Active with Event 19 to 7914 OpenConfirm then we never will and the connection will die. Open 7915 Confirm state means valid Open received so we must send a KeepAlive 7916 to acknowledge the Open (as pointed out in Jeff's other posting) and 7917 we never do it in OpenConfirm state itself (unless the KeepAlive 7918 timer expires which it cannot because we have not started it). 7920 So for me, OpenSent state Event 18 was and is correct, sending the 7921 KeepAlive without which the connection goes no further and Active 7922 state Event 19 needs to be brought into line. 7924 To say that the timer is started when entering Established state is 7925 fine except for a slight problem; we have no way in this FSM of 7926 defining actions that are taken on entering a state, only actions to 7927 be taken on leaving another state so that is why the KeepAlive 7928 actions need to be where they are (or are not in the case of Active 7929 state Event 19). 7931 Sue replied, asking more implementors to chime in on what they do for 7932 this part of the FSM. 7934 Curtis replied that we should: 7936 .in 4 Make it optional. Timing out in open or open-sent has never 7937 been much of an issue, so whether one or three keepalive get sent 7938 shouldn't be a hot topic. 7940 Sue said that this was fine, and she would work on text specifying 7941 optional. 7943 Jeff replied regarding GateD's behavior: 7945 .in 4 GateD will start its keepalive timer while in this state, so 7946 multiple keepalives will be sent. 7948 As someone previously said, this is a "yawn" issue. But to choose 7949 one way or the other, we may potentially make someone in non- 7950 compliance. 7952 From the closure of issue 12, we have this text, which discusses 7953 Keepalives to consider in relation to the other keepalive issue here: 7955 Change 1: new text 7957 Active state - event 19 7959 If an Open is received with the Open Delay timer is running [Event 7960 19], the local system - clears the connect retry timer (cleared to 7961 zero), - stops and clears the Open Delay timer - completes the BGP 7962 initialization, - stops and clears the Open Delay timer - sends an 7963 OPEN message, - send a Keepalive message, - if the hold timer value 7964 is non-zero, - starts the keepalive timer to initial value, - resets 7965 the hold timer to the negotiated value, else if the hold timer is 7966 zero - resets the keepalive timer (set to zero), - resets the hold 7967 timer to zero. 7969 - changes its state to OpenConfirm. 7971 .in 7 If the value of the autonomous system field is the same as the 7972 local Autonomous System number, set the connection status to an 7973 internal connection; otherwise it is "external". 7975 Since there were no more comments, this is at consensus. 7977 This was discussed in the "Comments 30-36" thread: Comment #33. And 7978 in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State 7979 (Keepalive timer set)" thread. 7981 3.53. Established State MIB 7983 Status: Consensus 7984 Change: No 7985 Summary: MIB references pulled in favor of having them in the MIB 7986 document. See issue 8. 7988 Discussion: 7990 This began with Siva asking: 7992 .in 4 Some event handling in the Established state do not set the MIB 7993 Reason when handling an event that causes an error. Can we add this 7994 ? 7995 Sue replied that we have pulled the MIB wording from the FSM. See 7996 issue 8. 7998 This was discussed in the "Comments 30-36" thread: Comment #34. 8000 3.54. State impact of not supporting Optional Events 8002 Status: Consensus 8003 Change: Yes 8004 Summary: Add the text at the end of the discussion section. 8006 Discussion: 8008 Siva stated that: 8010 .in 4 For the events whose status is optional, can we state the 8011 impact of not supporting them (in terms of any interoperability 8012 issues). I understand that most of the optional events will not have 8013 such an impact; but a clarification statement for the optional events 8014 would benefit new implementors. 8016 Sue responded: 8018 Much of the support of optional parameters depends on policy. I 8019 could put a short note about the optional events and parameters as 8020 part of 8.1.5 or 8.2.1.3 8022 I think it fits better in 8.1.5. Optional: Events: 3-8, 12, 13-14[my 8023 suggestion] 19, 22 Timers: Idle Hold Timer Open Delay Timer 8025 Required flags for optional parameters: Open Delay Flag BGP Stop Flap 8027 Sue said she would try to work up more if it is agreed that this is 8028 on the right track. 8030 Sue provided this text to clarify the behavior associated with 8031 Optional Attributes: 8033 8.2.1.3 FSM and Optional Attributes 8035 Optional Attributes specify either flags that augment the normal 8036 processing of the BGP FSM, or optional timers. If a Optional 8037 attribute can be set on a system, the Events and the BGP FSM actions 8038 must be support. For example, if the following options can be set in 8039 a BGP implementation: AutoStart and Passive TCP connection 8040 Establishment flag, then the events 3, 4 and 5 must be supported. 8042 If an Optional attribute cannot be set (that is declared always off 8043 logically), the events supporting that set of options do not have to 8044 be supported. 8046 This was discussed in the "Comments 30-36" thread: Comment #35. 8048 3.55. New DelayOpen State 8050 Status: Consensus 8051 Change: No 8052 Summary: We've chosen not to reopen the debate about adding a 8053 DelayOpen State to the FSM. 8055 Discussion: 8057 Siva began with asking: 8059 .in 4 Is delaying the sending of an OPEN message a standard industry 8060 practice ? 8062 Also, in the FSM, this has been handled by practically implementing a 8063 sub-state each, within the CONNECT and ACTIVE states. Won't the FSM 8064 look more simple if we just had a new DelayOpen state that we could 8065 move into ? 8067 Sue responded that this was something we have tried to do before, but 8068 that it spawned some degree of rabid response on both sides. Given 8069 our current mandate to stick with what is implemented, it is probably 8070 best not to reopen this debate. 8072 Unless someone badly wants to reopen this debate, the issue is at 8073 Consensus. 8075 This was discussed in the "Comments 21-30" thread: Comment #22. 8076 This was discussed in the "Comments 21-30" thread: Comment #26. 8077 This was discussed in the "Comments 30-36" thread: Comment #36. 8079 3.56. Clarify what is covered in the base document 8081 Status: Consensus 8082 Change: Yes 8083 Summary: Add the text at the end of the discussion to clarify what is 8084 documented where with regard to BGP and its extensions. 8086 Discussion: 8088 This grew out of a discussion on how to use BGP Identifiers in an 8089 IPv6-only environment. In that discussion it became clear that the 8090 way the documents are currently structured it is not clear to new 8091 readers that extension specifications can and do specify behavior 8092 that supersedes the behavior specified in the base spec. To that end 8093 it was agreed that this text should be added: 8095 .in 5 This document specifies the base behavior of the BGP protocol. 8096 This behavior can and is modified by extension specifications. When 8097 the protocol is extended the new behavior is fully documented in the 8098 extension specifications. 8100 This was discussed in the "Next-Hop in IPv6 only environments" 8101 thread. 8103 4. Security Considerations 8105 This document is an informational document that discusses the changes 8106 made in revising the BGP-4 specification. There are no security 8107 considerations applicable to this document. 8109 5. Normative References 8111 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 8112 (BGP-4)", RFC 1771, March 1995. 8114 Author's Address 8116 Andrew S. Lange 8117 Alcatel-Lucent 8119 Email: andrew.lange@alcatel-lucent.com