idnits 2.17.1 draft-ietf-idr-bgp-issues-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2406 has weird spacing: '...covered here ...' == Line 3001 has weird spacing: '...setting any B...' == Line 3026 has weird spacing: '...setting any B...' == Line 4922 has weird spacing: '...ing the follo...' == Line 5176 has weird spacing: '...en Sent to Id...' == (5 more instances...) == 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 (December 2003) is 7409 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 208, but not defined == Missing Reference: 'N' is mentioned on line 922, but not defined == Missing Reference: 'RWStevens' is mentioned on line 1290, but not defined == Missing Reference: 'RFC2385' is mentioned on line 4097, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Missing Reference: 'RFC2918' is mentioned on line 1693, but not defined == Missing Reference: 'RFC2842' is mentioned on line 1723, but not defined ** Obsolete undefined reference: RFC 2842 (Obsoleted by RFC 3392) -- Looks like a reference, but probably isn't: '1' on line 1826 == Missing Reference: 'RFC904' is mentioned on line 6400, but not defined -- Looks like a reference, but probably isn't: '12' on line 3029 -- Looks like a reference, but probably isn't: '10' on line 4086 == Missing Reference: 'RFC793' is mentioned on line 4094, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) -- Looks like a reference, but probably isn't: '13' on line 4649 == Missing Reference: 'Event17' is mentioned on line 8078, but not defined == Missing Reference: 'Event 18' is mentioned on line 8376, but not defined == Missing Reference: 'Event 19' is mentioned on line 8461, but not defined == Missing Reference: 'Event 14' is mentioned on line 7631, but not defined == Missing Reference: 'Event 13' is mentioned on line 6032, but not defined == Missing Reference: 'Event 17' is mentioned on line 8049, but not defined == Missing Reference: 'Event 22' is mentioned on line 6056, but not defined == Missing Reference: 'Event 15' is mentioned on line 6033, but not defined == Missing Reference: 'RFC3065' is mentioned on line 6224, but not defined ** Obsolete undefined reference: RFC 3065 (Obsoleted by RFC 5065) == Missing Reference: 'Event 1' is mentioned on line 6998, but not defined == Missing Reference: '3-6' is mentioned on line 7007, but not defined == Missing Reference: 'Event1' is mentioned on line 7007, but not defined == Missing Reference: 'Event24' is mentioned on line 7990, but not defined == Missing Reference: 'Event18' is mentioned on line 8137, but not defined == Missing Reference: 'Event2' is mentioned on line 8269, but not defined == Missing Reference: 'Event 2' is mentioned on line 8245, but not defined == Missing Reference: 'Event 25' is mentioned on line 8382, but not defined == Unused Reference: 'RFC1771' is defined on line 8621, but no explicit reference was found in the text == Unused Reference: 'BGP4Draft' is defined on line 8624, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-20 Summary: 9 errors (**), 0 flaws (~~), 38 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Lange 3 INTERNET DRAFT Cable & Wireless 4 June 2003 5 Expires December 2003 7 Issues in Revising BGP-4 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document records the issues discussed and the consensus reached 34 in the Interdomain Routing (IDR) Working Group during its efforts to 35 revise and bring up to date the base specification for the BGP-4 36 protocol. 38 Table of Contents 39 Status of this Memo......................................... 1 40 Abstract.................................................... 1 41 1. Introduction............................................. 5 42 2. The Issues from -17 to -18............................... 5 43 2.1 IDR WG Charter.......................................... 5 44 2.2 TCP Port................................................ 6 45 2.3 FSM wording for what state BGP accepts connections in... 7 46 2.4 BGP Identifier/Router ID................................ 7 47 2.5 Direct EBGP Peers....................................... 7 48 2.6 Disallow Private Addresses.............................. 8 49 2.7 Renumber Appendix Sections.............................. 8 50 2.8 Jitter Text............................................. 8 51 2.9 Reference to RFC904 - EGP Protocol...................... 13 52 2.10 Extending AS_PATH Attribute............................ 13 53 2.11 Rules for routes from Loc-RIB to Adj-RIB-Out - 54 Section 9.1............................................ 15 55 2.11.1 Rules for routes from Loc-RIB to Adj-RIB-Out - 56 Section 9.1.3........................................ 17 57 2.11.2 Rules for routes from Loc-RIB to Adj-RIB-Out - 58 Section 2............................................ 18 59 2.11.3 Documenting IBGP Multipath........................... 20 60 2.12 TCP Behavior Wording................................... 24 61 2.13 Next Hop for Originated Route.......................... 24 62 2.14 NEXT_HOP to Internal Peer.............................. 25 63 2.15 Grammer Fix............................................ 25 64 2.16 Need ToC, Glossary and Index........................... 26 65 2.17 Add References to other RFC-status BGP docs to base 66 spec................................................... 26 67 2.18 IP Layer Fragmentation................................. 26 68 2.19 Appendix Section 6.2: Processing Messages on a Stream 69 Protocol............................................... 27 70 2.20 Wording fix in Section 4.3............................. 28 71 2.21 Authentication Text Update............................. 28 72 2.22 Scope of Path Attribute Field.......................... 29 73 2.23 Withdrawn and Updated routes in the same UPDATE message 29 74 2.24 Addition or Deletion of Path Attributes................ 31 75 2.25 NEXT_HOP Semantics..................................... 32 76 2.26 Attributes with Multiple Prefixes...................... 32 77 2.27 Allow All Non-Destructive Messages to Refresh Hold 78 Timer.................................................. 33 79 2.28 BGP Identifier as Variable Quantity.................... 34 80 2.29 State Why Unresolveable Routes Should Be Kept in 81 Adj-RIB-In............................................. 34 82 2.30 Mention Other Message Types............................ 35 83 2.31 Add References to Additional Options................... 36 84 2.32 Clarify EGP Reference.................................. 36 85 2.32.1 EGP ORIGIN Clarification............................. 37 86 2.32.2 BGP Destination-based Forwarding Paradigm............ 41 87 2.33 Add "Optional Non-Transitive" to the MED Section....... 45 88 2.34 Timer & Counter Definition............................. 45 89 2.35 Fix Typo............................................... 46 90 2.36 Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 46 91 2.37 Combine "Unfeasible Routes" and "Withdrawn Routes"..... 46 92 2.38 Clarify Outbound Route Text............................ 48 93 2.39 Redundant Sentence Fragments........................... 49 94 2.40 Section 9.2.1.1 - Per Peer vs. Per Router 95 MinRouteAdvertisementInterval.......................... 50 97 2.41 Mention FSM Internal Timers............................ 50 98 2.42 Delete the FSM Section................................. 51 99 2.43 Clarify the NOTIFICATION Section....................... 51 100 2.44 Section 6.2: OPEN message error handling............... 52 101 2.45 Consistent References to BGP Peers/Connections/Sessions 54 102 2.46 FSM Connection Collision Detection..................... 55 103 2.47 FSM - Add Explicit State Change Wording................ 57 104 2.48 Explicitly Define Processing of Incoming Connections... 57 105 2.49 Explicitly Define Event Generation..................... 61 106 2.50 FSM Timers............................................. 62 107 2.51 FSM ConnectRetryCnt.................................... 62 108 2.52 Section 3: Keeping routes in Adj-RIB-In................ 63 109 2.53 Section 4.3 - Routes v. Destinations - Advertise....... 64 110 2.54 Section 4.3 - Routes v. Destinations - Withdraw........ 65 111 2.55 Section 4.3 - Description of AS_PATH length............ 67 112 2.56 Section 6 - BGP Error Handling......................... 68 113 2.57 Section 6.2 - Hold timer as Zero....................... 70 114 2.58 Deprecation of ATOMIC_AGGREGATE........................ 71 115 2.59 Section 4.3 - Move text................................ 79 116 2.60 Section 4.3 - Path Attributes.......................... 80 117 2.61 Next Hop for Redistributed Routes...................... 81 118 2.62 Deprecate BGP Authentication Optional Parameter from 119 RFC1771................................................ 83 120 2.63 Clarify MED Removal Text............................... 87 121 2.64 MED for Originated Routes.............................. 93 122 2.65 Rules for Aggregating with MED and NEXT_HOP............ 93 123 2.66 Complex AS Path Aggregating............................ 94 124 2.67 Counting AS_SET/AS_CONFED_*............................ 96 125 2.68 Outbound Loop Detection................................ 97 126 2.69 Appendix A - Other Documents........................... 99 127 3. The Issues from -18 to -19............................... 99 128 3.1 Reference to RFC 1772................................... 99 129 3.2 MUST/SHOULD Capitalization.............................. 99 130 3.3 Fix Update Error Subcode 7 -- accidently removed........ 100 131 3.4 Section 5.1.4 - Editorial Comment....................... 101 132 3.5 Section 9.1 - Change "all peers" to "peers"............. 101 133 3.6 AS Loop Detection & Implicit Withdraws.................. 101 134 3.7 Standardize FSM Timer Descriptions...................... 102 135 3.8 FSM MIB enumerations.................................... 103 136 3.9 Make "delete routes" language consistent................ 104 137 3.10 Correct OpenSent and OpenConfirm delete wording........ 104 138 3.11 Incorrect next state when the delay open timer expires. 105 139 3.12 Entering OpenConfirm / Adding "Stop OpenDelay" action.. 105 140 3.13 FSM Missing Next States................................ 111 141 3.13.1 FSM Missing Next States - Event 15 or 16 142 (Connect State)...................................... 111 143 3.13.2 FSM Missing Next States - Event 14 (Connect State)... 113 144 3.13.3 FSM Missing Next States - Event 15 or 16 145 (Active State)....................................... 115 146 3.13.4 FSM Missing Next States - Event 13-17 147 (TCP Connection)..................................... 116 148 3.13.5 FSM Missing Next States - Event 17 (Connect State)... 118 149 3.13.6 FSM Missing Next States - Event 18 (Open Confirm).... 121 150 3.14 FSM - Peer Oscillation Damping......................... 124 151 3.15 FSM - Consistent FSM Event Names....................... 124 152 3.16 Many Editorial Comments................................ 127 153 3.17 Section 3, Page 8, Paragraph 3 - Obsolete?............. 132 154 3.18 MED Removal Text....................................... 135 155 3.19 Security Considerations................................ 138 156 3.20 Peer Oscillation Damping............................... 138 157 3.21 Session Attributes - IdleHold Timer.................... 139 158 3.22 Specify New Attributes (Accept Connections/Peer 159 Oscillation Damping)................................... 141 160 3.23 Event1/Event2 Clean Up................................. 142 161 3.24 Events 3, 5, 6 & 7 Give Examples....................... 142 162 3.25 Event 4 & 5 Session Initiation Text.................... 144 163 3.26 Event 4 & 5 - bgp_stop_flap option..................... 145 164 3.27 Event 5 Clarification.................................. 147 165 3.28 Timer Events Definition - Make Consistent.............. 148 166 3.29 Event 8 - Clean Up..................................... 148 167 3.30 Hold Timer - Split?.................................... 149 168 3.31 OpenDelay Timer Definition............................. 149 169 3.32 Definition of TCP Connection Accept (Event 13)......... 149 170 3.33 Event 13 & 14 - Valid Addresses & Ports................ 150 171 3.34 Event 17 - TCP Connection Fails to TCP Connection 172 Termination............................................ 151 173 3.35 Making Definition Style Consistent..................... 151 174 3.36 Event 19 - Definition Cleanup.......................... 154 175 3.37 Event 22 - Cleanup..................................... 155 176 3.38 FSM Description - ConnectRetry Count................... 156 177 3.39 Handling Event 7 (Auto Stop to Idle State processing).. 157 178 3.40 Clearing the Connection Retry Timer.................... 157 179 3.41 Handling of Event 14 in the Connect State.............. 159 180 3.42 Handling events 20, 21 in the Connect State and Active 181 State.................................................. 160 182 3.43 Handling the default events in the Connect state....... 163 183 3.44 Handling Event 23 in Connect and OpenSent.............. 165 184 3.45 Event 17 in the Connect state.......................... 167 185 3.46 Handling of Event 17 in Active state................... 170 186 3.47 Handling of Event 19 in Active state................... 170 187 3.48 Handling of Event 2 in Active state.................... 171 188 3.49 Default Event handling in Active state................. 173 189 3.50 Clearing Hold timer in OpenSent, OpenConfirm and 190 Established State...................................... 173 191 3.51 Clearing Keepalive timer in OpenConfirm and Established 192 State.................................................. 174 194 3.52 Handling Event 18 in the OpenSent state (Keepalive 195 Timer)................................................. 174 196 3.53 Established State MIB.................................. 177 197 3.54 State impact of not supporting Optional Events......... 177 198 3.55 New DelayOpen State.................................... 178 199 3.56 Clarify what is covered in the base document........... 178 200 4. References............................................... 179 201 5. Author's Address......................................... 180 203 Specification of Requirements 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 1. Introduction 211 This document records the issues discussed and the consensus reached 212 in the Interdomain Routing (IDR) Working Group during its efforts to 213 revise and bring up to date the base specification for the BGP-4 214 protocol. The rational for doing this is simple: Experience has 215 demonstrated that the same issues and questions tend to come up again 216 and again. This memo will document not only the decisions on these 217 issues but also how and why the working group reached those 218 conclusions. We hope that this will help make future discussions 219 more fruitful by providing them with a historical context. 221 This document traces the evolution of the BGP-4 base specification 222 from its incarnation as draft-ietf-idr-bgp4-17.txt through the big 223 revision and update push culminating in draft-ietf-idr-bgp4-19.txt. 224 It is divided into two main sections. The first deals with the 225 issues discussed between -17 and -18, and the second deals with the 226 issues discussed between -18 and -19. 228 N.B. There is no rhyme or reason to the numbering scheme other than 229 unique tags to address the issues. 231 2. The Issues from -17 to -18. 233 This section lists the issues discussed on the list from late August 234 to late October 2002. 236 2.1 IDR WG Charter 238 Status: Consensus 239 Change: Yes 240 Summary: New charter adopted. 242 Discussion: 244 A variety of discussions surrounded the new charter. The rough 245 consensus is to accept the new charter that the AD's have proposed, 246 and to push as hard a possible to get the base spec to RFC status so 247 other drafts that are dependent can also move forward. 249 For our information, Alex has provided these approximate time lines: 251 Stage Anticipated delay Comment 252 -------------------------------------------------------------------- 253 AD-review 1-4 weeks The document may go back 254 depending on to the WG for the 255 workload AD-review comments to be 256 addressed; this would 257 introduce additional 258 delay. 260 IETF LC 2 weeks Same as above 262 IESG review & 1-2 weeks depending Same as above 263 telechat on when the IETF LC ends 264 -------------------------------------------------------------------- 266 Note that if the document is sent back to the WG at some stage, 267 required changes may warrant an additional WG Last Call. 269 I can personally commit to a 2-week upper bound for the AD-review 270 period. Bill may have a different timer granularity. 272 The opinions expressed on this were 7 in favor, 4 against. 274 This thread has messages subjects of "BGP spec and IDR WG charter" 275 and "IDR WG charter". 277 2.2 TCP Port 279 Status: Consensus 280 Change: Yes 281 Summary: 282 Change: "BGP uses TCP port 179 for establishing its connections." 283 To: "BGP listens on TCP port 179." 285 Discussion: 287 There has been a discussion on clarifying the wording in Section 2, 288 on which port BGP uses. The original text was: 290 "BGP uses TCP port 179 for establishing its connections." 292 The proposed new text is: 294 "BGP listens on TCP port 179." 296 There seems to be a rough consensus that the new text is better. 298 This thread has a message subject of "Review: Section 2, TCP Port 299 179" 301 2.3 FSM wording for what state BGP accepts connections in 303 Status: Consensus 304 Change: No 305 Summary: No change necessary 307 Discussion: 309 An issue was brought up later in the "Review: Section 2, TCP Port 310 179" thread about the words in the FSM for what state BGP accepts 311 connections in. The consensus is that the existing wording is clear. 313 2.4 BGP Identifier/Router ID 315 Status: Consensus 316 Change: No 317 Summary: No change necessary to base draft. Perhaps in a BCP. 319 Discussion: 321 The "admin dist/gp spec proposal", "Router ID" and "bgp spec 322 proposal" threads discussed the BGP Identifier and how close or not 323 it is to IGP's Router ID. The consensus was that this discussion is 324 better saved for a BCP draft, and that it does not need to be 325 contained in the base spec. 327 2.5 Direct EBGP Peers 329 Status: Consensus 330 Change: No 331 Summary: A recollection that ebgp peers must be direct. No text 332 proposed, no discussion. 334 Discussion: 336 Jonathan recalled something that stated that ebgp peers must be 337 direct. No specific sections were quoted. 339 Yakov responded to this with: 341 Section 5.1.3 talks about both the case where ebgp peers are 1 IP hop 342 away from each other: 344 2) When sending a message to an external peer X, and the peer is one 345 IP hop away from the speaker: 347 as well as the case where they are multiple IP hops away from each 348 other: 350 3) When sending a message to an external peer X, and the peer is 351 multiple IP hops away from the speaker (aka "multi hop EBGP"): 353 And emphasized that multi hop EBGP does exist. 355 This came up in the "bgp draft review" thread. 357 2.6 Disallow Private Addresses 359 Status: Consensus 360 Change: No 361 Summary: No change necessary 363 Discussion: 365 In the tread entitled "bgp draft review": 367 Mentioned explicitly disallowing private addresses. The consensus 368 was that there is no reason to disallow them. Which IP addresses 369 peers use is an operational issue. 371 2.7 Renumber Appendix Sections 373 Status: Consensus 374 Change: Yes 375 Summary: Rename/renumber appendix sections so they do not have the 376 same numbers as sections of the main text. 378 Discussion: 380 In the tread entitled "bgp draft review": 382 This thread brought up renaming sections in the appendix to avoid 383 confusion with sections of the same number in the main text. 385 Yakov responded that he would do so in the next edition. 387 2.8 Jitter Text 389 Status: Consensus 390 Change: Yes 391 Summary: 392 Get rid of section 9.2.1.3 ("Jitter"). Move the text to an 393 Appendix: "BGP Timers" Expand text to indicate that jitter applies 394 to all timers, including ConnectRetry. 396 The text for the appendix is listed at the end of the discussion. 398 Discussion: 400 In the tread entitled "bgp draft review": The thread also proposed: 402 "jitter should be applied to the timers associated with 403 MinASOriginationInterval, Keepalive, and 404 MinRouteAdvertisementInterval" 406 Be changed to: 408 "jitter should be applied to the timers associated with ConnectRetry 409 timer" 411 Yakov agreed with making some changes and suggested that we make sure 412 that jitter is applied to all timers. Specifically, he proposes we 413 get rid of section 9.2.1.3 ("Jitter"), move the text of this section 414 into Appendix "BGP Timers", and expand the text to indicate that 415 jitter applies to ConnectRetry timer as well. 417 Jonathan, the original commenter, agreed with Yakov's suggestion. 419 In a follow-up to this issue, there was a question raised about the 420 values we have specified for timers in the document. Specifically: 422 The ConnectRetry timer is should have a value that is 'sufficiently 423 large to allow TCP initialization. Application of jitter can reduce 424 the this value (by up to 25%). A configuration which the ConnectRetry 425 timer has been pegged at a value close to TCP connection time may 426 cause a connection to be terminated as a result of this jitter. Is 427 this a cause for concern ? 429 The default value suggested for ConnectRetry (120 seconds) is 430 sufficiently large that event with a jitter of 0.75, it will be 431 greater than TCP's connection establishment timer. 433 Is adding a jitter to the ConnectRetry timer a standard practice ? 434 What benefit does this provide ? 435 Curtis responded to this with: 437 The TCP connection establishment timer is 75 seconds (sysctl yield 438 "net.inet.tcp.keepinit: 75000" in BSD-oids). 440 The ConnectRetry determines when to make a second attempt after a 441 prior attempt to connect has failed. It is to avoid a rapid 442 succession of retries on immediate failures (for example "Connection 443 refused" if the peer was in the middle of a reboot, Network 444 Unreachable if you can't get there from here, etc) but also covers 445 the case where the TCP SYN goes off and is never heard from again. 447 And Jonathan replied with this information about current practice: 449 It seems to me that if you bring up all bgp peers at once it may lead 450 to load spikes on the network. Cisco seems to wait 27.5 +/- 2.5 451 seconds for IBGP, and 40 +/- 5 seconds for EBGP--20 sec. from config 452 time to the "open active, delay" jittered delay assignment plus the 453 jittered delay (5 to 10 sec. for IBGP, and 15 to 25 sec. for EBGP). 454 This would also apply for "no neighbor x.x.x.x shutdown". Their 455 value of ConnectRetry is 60sec. though, not sure how this value is 456 used (based on above). Maybe some Cisco folks can chime in on this 457 one??? 459 I did not check Juniper. 461 Also, interestingly, they do not apply jitter to the other timers (as 462 far as I can tell), but I don't see a problem with this. 464 Another timer that they use that is not mentioned in the draft/rfc is 465 the next hop resolution timer which is 30 seconds. Although it would 466 be nice to have this in the spec, I will concede that it is out of 467 scope and/or implementation dependent. 469 So the question that arises from this followup, is how does this 470 question affect the text of the appendix on jitter? 472 Curtis replied that we need to only state that jitter should be 473 applied to all timers. Whether a vendor does so or not is a minor 474 deficiency and does not bear on interoperability. Therefore, 475 specifying exact details are not necessary. 477 After Jonathan's response Curtis and Jonathan agreed that jitter 478 should be added to all timers and that we should state so in the 479 text. 481 Yakov proposed the following text for the appendix to discuss jitter: 483 I'd like to propose the following text for "BGP Timers" section: 485 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 486 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 487 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 488 9.2.1.1). 490 The suggested value for the ConnectRetry timer is 120 seconds. 492 The suggested value for the Hold Time is 90 seconds. 494 The suggested value for the KeepAlive timer is 1/3 of the Hold Time. 496 The suggested value for the MinASOriginationInterval is 15 seconds. 498 The suggested value for the MinRouteAdvertisementInterval is 30 499 seconds. 501 An implementation of BGP MUST allow the Hold Time timer to be 502 configurable, and MAY allow the other timers to be configurable. 504 To minimize the likelihood that the distribution of BGP messages by a 505 given BGP speaker will contain peaks, jitter should be applied to the 506 timers associated with MinASOriginationInterval, Keepalive, 507 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 508 shall apply the same jitter to each of these quantities regardless of 509 the destinations to which the updates are being sent; that is, jitter 510 will not be applied on a "per peer" basis. 512 The amount of jitter to be introduced shall be determined by 513 multiplying the base value of the appropriate timer by a random 514 factor which is uniformly distributed in the range from 0.75 to 1.0. 516 Jeff & Ben agreed with this. 518 Justin suggested that we move the range from 0.75 to 1.25 to ensure 519 that the average is around the configured value. Yakov agreed with 520 Justin's changes. Jonathan disagreed, arguing that it was out-of- 521 scope for the task of clarifying the text only. Justin agreed and 522 withdrew his comment. 524 Curtis liked the general text, but suggested these modifications: 526 minor improvement (not really an objection) -- s/suggested 527 value/suggested default value/g 529 Also 530 s/shall apply the same jitter/may apply the same jitter/ (to each of 531 these quantities regardless of ...). 533 s/jitter will not be applied/jitter need not be configured/ (on a 534 "per peer" basis). 536 He stated that in Avici's implementation they allow a lot of 537 granularity in timer settings, so this reflects current practice. 539 Curtis also suggested changing the last paragraph: 541 The suggested default amount of jitter shall be determined by 542 multiplying the base value of the appropriate timer by a random 543 factor which is uniformly distributed in the range from 0.75 to 1.0. 544 A new random value should be picked each time the timer is set. The 545 range of the jitter random value MAY be configurable. 547 This would make it clear that it is possible to have this timer as 548 configurable and still be within spec. 550 Other comments on Yakov's text pointed out that IOS uses 5 seconds as 551 the default IBGP MinRouteAdvertisementInterval. 553 Tom pointed out that there seems to be a discrepancy between this 554 text and the FSM: The FSM has an OpenDelay timer. And the FSM 555 suggests a HoldTimer of 4 minutes. 557 In following up on this issue, Yakov stated: 559 Here is the final text for the BGP Timers section: 561 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 562 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 563 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 564 9.2.1.1). 566 The suggested default value for the ConnectRetry timer is 120 567 seconds. 569 The suggested default value for the Hold Time is 90 seconds. 571 The suggested default value for the KeepAlive timer is 1/3 of the 572 Hold Time. 574 The suggested default value for the MinASOriginationInterval is 15 575 seconds. 577 The suggested default value for the MinRouteAdvertisementInterval is 578 30 seconds. 580 An implementation of BGP MUST allow the Hold Time timer to be 581 configurable, and MAY allow the other timers to be configurable. 583 To minimize the likelihood that the distribution of BGP messages by a 584 given BGP speaker will contain peaks, jitter should be applied to the 585 timers associated with MinASOriginationInterval, Keepalive, 586 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 587 may apply the same jitter to each of these quantities regardless of 588 the destinations to which the updates are being sent; that is, jitter 589 need not be configured on a "per peer" basis. 591 The suggested default amount of jitter shall be determined by 592 multiplying the base value of the appropriate timer by a random 593 factor which is uniformly distributed in the range from 0.75 to 1.0. 594 A new random value should be picked each time the timer is set. The 595 range of the jitter random value MAY be configurable. 597 With this in mind, I would suggest we mark this issue as closed. 599 Jonathan suggested adding "per peer" to the text, Yakov responded 600 with this text: 602 An implementation of BGP MUST allow the Hold Time timer to be 603 configurable on a per peer basis, and MAY allow the other timers to 604 be configurable. 606 This proposal met with general agreement. This issue is at 607 consensus. 609 2.9 Reference to RFC904 - EGP Protocol 611 Status: Consensus 612 Change: Yes 613 Summary: Add a reference to RFC904 615 Discussion: 617 The "Review Comment: Origin Attribute pg 14" thread suggested adding 618 a reference to RFC904(?), to refer to the EGP protocol. There was no 619 discussion. 621 Yakov agreed to this, and Jonathan seconded it. 623 2.10 Extending AS_PATH Attribute 625 Status: Consensus 626 Change: Yes 627 Summary: Add this to 9.2: 629 If due to the limits on the maximum size of an UPDATE message (see 630 Section 4) a single route doesn't fit into the message, the BGP 631 speaker MUST not advertise the route to its peers and may choose to 632 log an error locally. 634 Discussion: 636 The "Extending AS_PATH attribute length en route" thread brought up 637 the issue of what action should we specify when we receive a route 638 with an AS_PATH that exceeds the defined maximum length. There was 639 some discussion, and it was suggested that, after logging the error, 640 the route not be propagated. 642 Yakov stated that: 644 The real issue here is how to handle the case when a route (a single 645 address prefix + path attributes) doesn't fit into 4K bytes (as the 646 max BGP message size is 4 K). To address this issue I would suggest 647 to add the following to 9.2: 649 After some discussion, Yakov's proposed text's last sentence was 650 dropped and we arrived at: 652 If due to the limits on the maximum size of an UPDATE message (see 653 Section 4) a single route doesn't fit into the message, the BGP 654 speaker may choose not to advertise the route to its peers. 656 In response to Andrew's clarification question to the list, Curtis 657 responded: 659 Wording would be more like: 661 If the attributes for a specific prefix becomes too large to fit the 662 prefix into the maximum sized BGP UPDATE message, the prefix should 663 not be advertised further. Truncation or omission of attributes 664 should not occur unless policies for such modifications are 665 specifically configured. Such policies may contribute to the 666 formation of route loops and are not within the scope of this 667 protocol specification. 669 After some additional discussion, it was decided that we add "and may 670 choose to log an error locally." to the end of Yakov's text. 672 Also, we agreed to change "may choose not to advertise..." to "MUST 673 NOT advertise...". 675 So the text on the table right now is: 677 If due to the limits on the maximum size of an UPDATE message (see 678 Section 4) a single route doesn't fit into the message, the BGP 679 speaker MUST not advertise the route to its peers and may choose to 680 log an error locally. 682 This met with one agreement and no disagreements. We have a 683 consensus. 685 2.11 Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 687 Status: Consensus 688 Change: Yes 689 Summary: Add this text: 691 The local speaker SHALL then install that route in the Loc-RIB, 692 replacing any route to the same destination that is currently being 693 held in the Loc-RIB. When the new BGP route is installed in the Rout- 694 ing Table, care must be taken to ensure that existing routes to the 695 same destination that are now considered invalid are removed from the 696 Routing Table. Whether or not the new BGP route replaces an existing 697 non-BGP route in the Routing Table depends on the policy configured 698 on the BGP speaker. 700 Discussion: 702 The "Proxy: comments on section 9.1.3" thread brought up some lack of 703 clarity in the section discussing the rules for which routes get 704 propagated from the Loc-RIB into the Adj-RIB-Out. These discussions 705 resulted in a number of suggestions for new text. 707 The first new text was proposed to clarify the issue that the thread 708 first brought up: 710 I agree that this could use some clarification. How about adding 711 to b) in section 9.1: 713 The Loc-RIB must contain only one route per destination; further, it 714 must include all routes that the BGP speaker is using. 716 changing c) in section 9.1.2 to: 718 c) is selected as a result of the Phase 2 tie breaking rules 719 specified in 9.1.2.2, or 720 and adding 722 d) when routing protocols other than BGP are in use, is determined by 723 some other local means to be the route that will actually be used to 724 reach a particular destination. 726 This text was never discussed or a consensus formed on putting it in 727 the document. 729 This modification to 9.1.2 was also proposed to address the same 730 concern: 732 How about changing the paragraph after c) in 9.1.2 to: 734 The local speaker SHALL then install that route in the Loc-RIB, 735 replacing any route to the same destination that is currently being 736 held in the Loc-RIB. This route SHALL then also be installed in the 737 BGP speakers forwarding table. 739 There was one response in the negative to this change, arguing that 740 is is not necessary. 742 Yakov replied to this that: 744 Wrt "adding to b) in section 9.1", the second part (after ";") is 745 redundant as this point is already stated in 3.2. Wrt the first point 746 about Loc-RIB containing just one route per destination, I would 747 suggest to add it to section 3.2, where Loc-RIB is first introduced, 748 rather than adding it to 9.1. 750 Wrt "changing c)... and adding...", I have no objections to 751 add/modify the text, as suggested above. 753 I am not sure though that changing the paragraph after c) in 9.1.2 is 754 really necessary though, so I would prefer to keep it as is. 756 The "issue 11" thread this was being discussed in then digressed to 757 the topic, now covered in issue 11.3. 759 Ben re-addressed the original issue with this input: 761 I have somewhat of an issue with the paragraph after item c section 762 9.1.2 as discussed. 764 which is => 766 "The local speaker SHALL then install that route in the Loc-RIB, 767 replacing any route to the same destination that is currently being 768 held in the Loc-RIB. If the new BGP route is installed in the Routing 769 Table (as a result of the local policy decision), care must be taken 770 to ensure that invalid BGP routes to the same destination are removed 771 from the Routing Table. Whether or not the new route replaces an 772 already existing non-BGP route in the routing table depends on the 773 policy configured on the BGP speaker." 775 Can we assume that its OK to have a route present in the Loc-RIB and 776 possibly in the adj-RIB-Out but not in the Routing table due to some 777 policy. Won't we violate rule number 1? Only advertise what you use. 779 As conversely implied in this sentence => 781 "If the new BGP route is installed in the Routing Table (as a result 782 of the local policy decision), care must be taken to ensure that 783 invalid BGP routes to the same destination are removed from the 784 Routing Table" 786 I would rephrase the paragraph as follows => 788 "The local speaker SHALL then install that route in the Loc-RIB, 789 replacing any route to the same destination that is currently being 790 held in the Loc-RIB. When the new BGP route is installed in the 791 Routing Table, care must be taken to ensure that existing routes to 792 the same destination that are now considered invalid are removed from 793 the Routing Table. Whether or not the new BGP route replaces an 794 existing non-BGP route in the routing table depends on the policy 795 configured on the BGP speaker." 797 Jeff replied: 799 With the exception that Routing Table should be capitalized 800 throughout, I'd suggest we take this as consensus. 802 Yakov agreed. We are at consensus. 804 2.11.1 Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3 806 Status: Consensus 807 Change: Yes 808 Summary: The text below will be added to the -18 version. 810 Discussion: 812 In further discussions around this issue, this text was also 813 proposed: 815 How about adding to section 9.1.3, at the end: 817 Any local-policy which results in reachability being added to an Adj- 818 RIB-Out without also being added to the local BGP speaker's 819 forwarding table is beyond the scope of this document. 821 This suggestion received one response that agreed to this change. 823 This text will be added to the -18 version, and since there were no 824 objections, this issue has been moved to consensus. 826 2.11.2 Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2 828 Status: Consensus 829 Change: Yes 830 Summary: Add this text: 832 In the context of this document we assume that a BGP speaker 833 advertises to its peers only those routes that it itself uses (in 834 this context a BGP speaker is said to "use" a BGP route if it is the 835 most preferred BGP route and is used in forwarding). All other cases 836 are outside the scope of this document. 838 Discussion: 840 Additionally this thread produced this section of new text, in 841 section 2: 843 845 "one must focus on the rule that a BGP speaker advertises to its 846 peers (other BGP speakers which it communicates with) in neighboring 847 ASs only those routes that it itself uses." 849 Should be changed to 851 853 "one must focus on the rule that a BGP speaker advertises to its 854 peers (other BGP speakers which it communicates with) in neighboring 855 ASs only routes whose NLRIs are locally reachable." 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 routes which are locally reachable. Local reachability can 862 be achieved by having any protocol route to the given destination in 863 the routing table." 864 There were a lot of emails exchanged on this topic with a variety of 865 texts proposed (see early in the "Active Route" thread). This issue 866 reopened with Jonathan, who brought up the issue originally, stating 867 that: 869 The issue I raised, and would like to be [re-]considered is with: 871 "one must focus on the rule that a BGP speaker advertises to its 872 peers (other BGP speakers which it communicates with) in neighboring 873 ASs only those routes that it itself uses." 875 Curtis replied that: 877 That is called route origination and it is allowed by: 879 9.4 Originating BGP routes 881 A BGP speaker may originate BGP routes by injecting routing 882 information acquired by some other means (e.g. via an IGP) into BGP. 883 [...] The decision whether to distribute non-BGP acquired routes 884 within an AS via BGP or not depends on the environment within the AS 885 (e.g. type of IGP) and should be controlled via configuration. 887 Advice on what to put in the AS_PATH and NEXT_HOP is in the document. 889 He continued with: 891 I don't think there was ever consensus on what to do with the 892 statement "a BGP speaker advertises to its peers (other BGP speakers 893 which it communicates with) in neighboring ASs only those routes that 894 it itself uses". Some reasonable choices are: 896 1. Omit it (the implied consensus of the rewrite of the paragraph in 897 32.2). 899 2. Leave it as is and put it in another paragraph to separate it 900 from the destination based routing statement. 902 3. Clean up the wording and put it in another paragraph to separate 903 it from the destination based routing statement. 905 The separate paragraph for 2 would be the exact sentence we now have. 907 A BGP speaker advertises to its peers (other BGP speakers which it 908 communicates with) in neighboring ASs only those routes that it 909 itself uses. 911 In possibility 3 we (try to) clear up the ambiguity about the meaning 912 of the word "use" in this sentence. 914 A BGP speaker advertises to its peers (other BGP speakers which it 915 communicates with) in neighboring ASs only those routes that it 916 itself uses. In this context a BGP speaker is said to "use" a BGP 917 route if it is the most preferred BGP route and is either directly 918 used in forwarding or in a specifically configured case where the BGP 919 route would be forwarded internally but IGP forwarding information is 920 used. The latter case reflects a usage in which the IGP is used for 921 forwarding but BGP is originated to IBGP to carry attributes that 922 cannot be carried by the IGP (for example, BGP communities [N]). 923 Other special cases such as virtual routers and multiple instances of 924 BGP on a single router are beyond the scope of this document but for 925 each of these the statement "a BGP speaker advertises to its peers 926 (other BGP speakers which it communicates with) in neighboring ASs 927 only those routes that it itself uses" can (and should in the 928 definition of the extension) be made true with an appropriate 929 definition of the word "use". 931 Unless someone volunteers better wording this may be a good starting 932 point. I thing the last sentence borders on ridiculous in a protocol 933 spec but may be necessary to address specific objections raised on 934 this mailing list. If we want to elaborate on the meaning of the 935 word "use" and address the objections this is what we end up with. 937 Of course looking at what we ended up with, I'd also go along with 938 the other two options (leave it out or put the one sentence in a 939 separate paragraph as is). 941 After some additional discussion (in the "issue 11.2" thread), we 942 have come to a consensus on this text: 944 In the context of this document we assume that a BGP speaker 945 advertises to its peers only those routes that it itself uses (in 946 this context a BGP speaker is said to "use" a BGP route if it is the 947 most preferred BGP route and is used in forwarding). All other cases 948 are outside the scope of this document. 950 This issue is at consensus. 952 2.11.3 Documenting IBGP Multipath 954 Status: Consensus 955 Change: Yes 956 Summary: The documenting of IBGP Multipath is left to another 957 Internet Draft. The consensus is that it should not be in the base 958 spec. 960 Discussion: 962 This thread began in the "issue 11" discussion. In it it was 963 proposed that: 965 There is support in some router vendors to allow more than one BGP 966 route to be installed, for the purpose for load balancing. Given that 967 this is a current practice, and seems to be a useful feature as well, 968 should we insist that only one route be installed in the Loc-RIB ? 970 I would like to suggest that all sections which use MUST in the 971 context of only one route in Loc-RIB be relaxed a little to a SHOULD, 972 and a section added that states that it is possible for a n 973 implementation to add more than one route to the Loc-RIB for the 974 purposes of load balancing. 976 While it will be useful to describe how this situation is the 977 handler, it is perhaps sufficient to even state that handling of this 978 situation is outside the scope of this RFC. 980 I am including some proposed text for this purpose: 982 For the part: 984 > The Loc-RIB must contain only one route per destination; 986 consider instead, 988 % The Loc-RIB SHOULD contain only one route per destination. % An 989 implementation may choose to install multiple routes to % a 990 destination (for the purposes of load balancing). The % handling of 991 such a configuration, however, is outside the % scope of this RFC. 993 Perhaps, this can be in section 3.2 instead. 995 After much discussion back and forth, it was agreed that documenting 996 IBGP Multipath behavior is a good thing. However, it is something 997 that belongs in another draft. 999 Alex opened this issue up again. There were a flurry of responses, 1000 most all of them agreeing with the original consensus that we should 1001 document this feature in a different draft, since it doesn't affect 1002 the core interoperability requirements, and we want to advance the 1003 spec in a timely manner. 1005 Alex persisted in his assertion that this belongs in the base 1006 specification. Right now, the issue is still open. 1008 This discussion later expanded in scope to include all BGP multipath. 1010 Curtis laid out a good description of the various flavors of 1011 multipath: 1013 In addition to IGP multihop, there are two cases of BGP multipath. 1015 In IGP multihop there is one BGP advertisement but to ways to reach 1016 th BGP NEXT_HOP via the IGP. 1018 In one case of BGP multihop, two (or more) IBGP routers peering with 1019 the same external AS have equal routes to a destination and are an 1020 equal cost away from a third router. BGP multihop is applicable to 1021 that third router. Without BGP multihop, BGP would normally pick the 1022 BGP NEXT_HOP of the advertisement from only one of those IBGP peers 1023 (using BGP Identifier) and use that. The IGP lookup would yield one 1024 next hop. With BGP multihop, BGP uses the BGP NEXT_HOP of both 1025 advertisements. Each BGP NEXT_HOP has a different IGP next hop (one 1026 or more IGP next hop). 1028 The second case is where all of the candidates routes for BGP 1029 multipath are external. Seldom does IGP multipath come into play for 1030 EBGP (odd tunneled EBGP multihop cases maybe). Typically the load is 1031 split among two (or more) routers in the same AS. 1033 If in EBGP multipath you split among routers in difference AS, an 1034 aggregate should be formed. This is still prior to the IGP cost rule 1035 in the route selection. 1037 Normally one would not combine IBGP and EBGP in multihop given that 1038 the decision point for multihop is after "d" in 9.1.2.2. If the 1039 multihop decision was prior to "d", then two routers each with an 1040 external peering would forward some of the traffic to each other and 1041 for some src/dst pairs, they'd form a loop. [So don't do that!] 1043 This is getting to be a lot to add to the base spec. I hope we've 1044 convinced you that we should put it in another document. 1046 Curtis later added specific text, that could serve as a start for the 1047 new document (or added to the base spec if the consensus ended up 1048 going the other way): 1050 BGP specifies how to select the single best route. OSPF specifically 1051 defines procedures for handling equal cost multipath (ECMP) [cite 1052 OSPF]. The same technique has been applied to ISIS. A similar 1053 technique has been used with BGP. Variations exist but the decision 1054 to support BGP multipath, the specific variation of BGP multipath, or 1055 not to support it, does not affect interoperability. 1057 A naive implementations of ECMP can cause severe performance 1058 degradation for TCP flows. To avoid this, implementations of BGP 1059 multipath SHOULD maintain packet ordering within microflows as 1060 described in [cite rfc2991, rfc2992]. 1062 BGP multipath, if implemented, SHOULD be disabled by default. 1064 In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there 1065 are two variations of BGP multipath described here. A BGP 1066 implementation may offer both, either one, or neither variation of 1067 BGP multipath. Other variations of BGP multipath may exist, but no 1068 guarantees can be made in this protocol specification of their 1069 properties or impact on interoperability. 1071 Where IGP multipath is used, there is an interaction with BGP learned 1072 routes. The lookup of a BGP NEXT_HOP in the IGP can result in the 1073 selection of an IGP multipath entry. This is not a variation of BGP 1074 multipath. When this occurs, one BGP route is selected as the best 1075 but there is more than one way to reach the BGP NEXT_HOP via the IGP. 1077 In one variation of BGP multipath, a set of more than one IBGP 1078 routers peering with the same external AS have equal routes to a 1079 destination and are an equal IGP cost away from a second set of one 1080 or more routers. BGP multipath is applicable to the latter set of 1081 routers. Without BGP multipath, BGP would pick the BGP NEXT_HOP of 1082 the advertisement from only one of those IBGP peers (using BGP 1083 Identifier) and use only that BGP route. With BGP multipath, BGP 1084 uses the BGP NEXT_HOP of more than one of these equal cost 1085 advertisements, yielding more than one BGP NEXT_HOP. Each BGP 1086 NEXT_HOP has a different IGP next hop (one or more IGP next hop if 1087 IGP multipath is in use). 1089 The second case is where all of the candidates routes for BGP 1090 multipath are external and learned by a single BGP peer. Without BGP 1091 multipath this peer would select only one of the BGP routes and 1092 obtain only one BGP NEXT_HOP. With BGP multipath, more than one 1093 equal cost route is selected yielding more than one BGP NEXT_HOP. 1094 Seldom does IGP multipath come into play when looking up an EBGP 1095 NEXT_HOP but could in principle be applicable. 1097 If in EBGP multipath traffic is split among routers in difference AS, 1098 an aggregate SHOULD be formed so as to propagate a route with an 1099 accurate AS_PATH. If the resulting aggregate is not more specific 1100 than the components, the AS_SET SHOULD NOT be dropped. 1102 The decision point for multipath is after step "d" in Section 9.1.2.2 1103 (prefer externally learned routes). IBGP learned and EBGP learned 1104 routes MUST NOT be combined in multipath. If the multipath decision 1105 is prior to "d", then two routers each with an external peering would 1106 form a routing loop. 1108 The decision point for multipath is generally after step "e" in 1109 Section 9.1.2.2. Some relaxation of the "equal cost" rule (also 1110 applicable to IGP multipath) is possible. In addition to the equal 1111 cost BGP NEXT_HOPS available at BGP route selection, if the IGP next 1112 hop for other BGP NEXT_HOPs are of lower cost, then those may be used 1113 as well. This relaxation of the step "e" is possible but is not 1114 widely implemented (and may not be implemented at all). 1116 The consensus of the majority of the IDR WG is to keep this in a 1117 separate draft and out of the base spec. 1119 2.12 TCP Behavior Wording 1121 Status: Consensus 1122 Change: No 1123 Summary: In issue 19 we decided to remove this section entirely. As 1124 a result the previous consensus on this issue (no change) is needed 1125 moot. 1127 Discussion: The subject-less "your mail" thread discussed a wording 1128 clarification from: 1130 "An implementation that would "hang" the routing information process 1131 while trying to read from a peer could set up a message buffer (4096 1132 bytes) per peer and fill it with data as available until a complete 1133 message has been received. " 1135 To something that is more TCP-correct, such as: 1137 "An implementation that would "hang" the routing information process 1138 while trying to received from a peer could set up a message buffer 1139 (4096 bytes) per peer and fill it with data as available until a 1140 complete message has been received. " 1142 (only change: "read" to "received" This was one of a couple of 1143 suggested changes.) 1145 This suggestion was quite contentious, and although there were a 1146 variety of alternate texts proposed, the only consensus was that this 1147 was a very minor issue, and probably not worth changing. 1149 In issue 19 we decided to remove this section entirely. 1151 2.13 Next Hop for Originated Route 1152 Status: Consensus 1153 Change: No 1154 Summary: No responses, assumed consensus to keep things the same. 1156 Discussion: 1158 There was a one-message thread entitled "next hop for originated 1159 route". This message received no response, so the assumption is that 1160 there is a consensus to keep things as they are. 1162 For related discussion see issue 61. 1164 2.14 NEXT_HOP to Internal Peer 1166 Status: Consensus 1167 Change: No 1168 Summary: Closed in favor of issue 61. 1170 Discussion: 1172 The thread entitled "NEXT_HOP to internal peer" starts with this 1173 question: 1175 When sending a locally originated route to an internal peer, what 1176 should NEXT_HOP be set to? 1178 One response suggested that we add a line stating that the NEXT_HOP 1179 address originates from the IGP. 1181 Since this issue and issue 61 are basically the same, except 61 1182 proposes text, we'll close this issue in favor of 61. 1184 2.15 Grammar Fix 1186 Status: Consensus 1187 Change: Yes 1188 Summary: Change: "The Prefix field contains IP address prefixes ..." 1189 To: "contains an IP address prefix ..." 1191 Discussion: The thread entitled "Review comment: bottom of page 16" 1192 corrects a grammar mistake by suggesting we change: 1194 "The Prefix field contains IP address prefixes ..." 1196 to: 1198 "contains an IP address prefix ..." 1199 Yakov responded that this will be fixed in -18. 1201 The consensus seems to be to correct this, and go with the new text. 1203 2.16 Need ToC, Glossary and Index 1205 Status: Consensus 1206 Change: Yes 1207 Summary: Need to add a Table of Contents (ToC), Glossary and Index to 1208 the draft. Will be added in draft -18. 1210 Discussion: 1212 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests: 1214 1. Document needs, Table of Contents, Glossary, and Index 1216 2. Paths, Routes, and Prefixes need to be defined in the spec early 1217 on (like in a glossary), so it is obvious what is implied. 1219 Yakov responded that draft -18 will have a ToC and definition of 1220 commonly used terms. 1222 2.17 Add References to other RFC-status BGP docs to base spec. 1224 Status: Consensus 1225 Change: Yes 1226 Summary: Add references to other RFC-status BGP docs to the base 1227 spec. 1229 Discussion: 1231 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes 1232 titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to 1233 suggest: 1235 3. All BGP Extensions described in other documents that made it to 1236 RFC status should be at least referenced in the Reference section 1237 P.64. This is justifiable since it's the core BGP standard spec. 1239 Yakov responded that this will be added to the -18 review. 1241 Jonathan agreed. 1243 2.18 IP Layer Fragmentation 1245 Status: Consensus 1246 Change: No 1247 Summary: No need to mention IP Layer Fragmentation in the BGP 1248 specification, since this is taken care of at the TCP level. 1250 Discussion: 1252 1. P.6 section 4. Message Formats, its possible for the source BGP 1253 peer IP layer to fragment a message such that the receiving BGP peer 1254 socket layer would have to reassemble it. Need to mention this, since 1255 BGP implementations are required to do this. 1257 The response to this was that, while true, reassembly is something 1258 that is inherent in the TCP layer that BGP rides over. Therefore, 1259 this is something that is in the TCP spec, and needn't be repeated in 1260 the BGP spec. This comment was reaffirmed. There seems to be 1261 consensus that this isn't something that needs to be in the BGP spec. 1263 2.19 Appendix Section 6.2: Processing Messages on a Stream Protocol 1265 Status: Consensus 1266 Change: Yes 1267 Summary: Remove the section entirely, as this is something that does 1268 not belong in the base spec. 1270 Discussion: 1272 This first came up in response to Issue 17: 1274 There was one comment suggesting that section 6.2 (Processing 1275 Messages on a Stream Protocol" mentioned this. 1277 The original reviewer responded that the out-of-scope comment was 1278 out-of-place and referred the responder to section 6.2 (appendix 6) 1280 The original reviewer stated that he is happy with just adding a 1281 reference to section 6.2 in appendix 6 and leaving it at that. 1283 Curtis suggested we just add a reference to Stevens in appendix 6. 1284 6.2 and be done with it. Specifically: 1286 6.2 Processing Messages on a Stream Protocol 1288 BGP uses TCP as a transport mechanism. If you are unsure as to how 1289 to handle asynchronous reads and writes on TCP sockets please refer 1290 to Unix Network Programming [RWStevens] or other introductory text 1291 for programming techniques for the operating system and TCP 1292 implementation that you are using. 1294 There were further suggestions to remove the section entirely as out- 1295 of-scope. At least 3 people agreed with this. 1297 Alex responded that he sees no reason to remove it, but wouldn't have 1298 a problem if the WG decides to do so. 1300 There seems to be general agreement that this section should be 1301 removed. 1303 N.B. This also affects issue 12. 1305 2.20 Wording fix in Section 4.3 1307 Status: Consensus 1308 Change: Yes 1309 Summary: A small change for clarity in section 4.3 1311 Discussion: 1313 This suggestion grew out of the discussion on Issue 18. 1315 The following change was suggested in section 4.3, second line of the 1316 first paragraph: 1318 s/UPDATE packet/UPDATE message/ 1320 Yakov agreed to this change and updated the draft. 1322 2.21 Authentication Text Update 1324 Status: Consensus 1325 Change: No 1326 Summary: The consensus is that additional references to RFC2385 are 1327 not necessary. 1329 Discussion: 1331 P. 10, "Authentication Data:" section you might want to add this, It 1332 is also possible to use MD5 (RFC2385) at the transport layer to 1333 validate the entire BGP message. 1335 Yakov replied to this: 1337 There is already text that covers this: 1339 "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may 1340 be used in addition to BGP's own authentication mechanisms." 1342 .... 1344 "In addition, BGP supports the ability to authenticate its data 1345 stream by using [RFC2385]." 1347 So, I see no need to add the text proposed above. 1349 Ishi agreed with Yakov. Jonathan disagreed since he thought no one 1350 uses BGP auth. Ishi replied that there are lots of people who do use 1351 it. Jonathan replied with a clarification question: "Who uses *BGP's 1352 own* authentication mechanisms???" Ron Bonica replied that they use 1353 BGP auth. There was some additional discussion over who implements 1354 simple password authentication vs. MD5. 1356 After further discussion, the consensus seems to be that we should 1357 leave the text as it is for the reasons Yakov pointed out. There was 1358 some discussion over opening a new issue to discuss deprecating the 1359 BGP auth mechanism discussed in RFC1771 in favor of the mechanism in 1360 RFC2385. 1362 The issue of Deprecating BGP AUTH is discussed in issue 62. 1364 2.22 Scope of Path Attribute Field 1366 Status: Consensus 1367 Change: Yes 1368 Summary: This is already being covered by text that has been added to 1369 the -18 draft. 1371 Discussion: 1373 P. 12, right after "Path Attributes". The following sentence should 1374 be added to this section to clarify the scope of the Path Attribute 1375 field. "All attributes in the Path Attribute field represent the 1376 characteristics of all the route prefixes defined in the NLRI field 1377 of the message". 1379 Yakov replied to this that: 1381 This will be covered by the following text in 3.1 that will be in the 1382 -18 version (see also issue 54). 1384 Routes are advertised between BGP speakers in UPDATE messages. 1385 Multiple routes that have the same path attributes can be advertised 1386 in a single UPDATE message by including multiple prefixes in the NLRI 1387 field of the UPDATE message. 1389 Therefore there is no need to add the sentence proposed above. 1391 There were no objections to this statement, so this issue has been 1392 moved into consensus. 1394 2.23 Withdrawn and Updated routes in the same UPDATE message 1396 Status: Consensus 1397 Change: No 1398 Summary: For various reasons, not least of which is compatibility 1399 with existing implementations, the decision was made to keep thing 1400 the way they are. 1402 Discussion: 1404 4. P.16, last paragraph in section 4.3 as stated, "An UPDATE message 1405 should not include the same address prefix in the WITHDRAWN ROUTES 1406 and Network Layer Reachability Information fields, however a BGP 1407 speaker MUST be able to process UPDATE messages in this form. A BGP 1408 speaker should treat an UPDATE message of this form as if the 1409 WITHDRAWN ROUTES doesn't contain the address prefix." 1411 This complexity could have been avoided if withdrawn routes and NLRI 1412 prefixes with their attributes were mutually exclusive of each other 1413 and appeared in different update messages. If that was the case, the 1414 priority of which field to process first would have been as simple as 1415 using "first come, first served" message processing approach. 1417 Yakov commented that this would make the case where they are both in 1418 the same message unspecified. 1420 John commented that this is something we don't want to change this 1421 late in the game. Although it was acknowledged that this might be a 1422 good change if we were working from a clean slate. 1424 Ben acceded that this was somewhat wishful thinking on his part. 1426 Curtis's comment seems to coincide with this message, stating: 1428 The existing rules are very clear. 1430 Summarized: 1432 If an UPDATE contains only a withdraw for a prefix, then withdraw 1433 whatever route the peer had previously sent. 1435 If an UPDATE contains the prefix only in the NLRI section, replace 1436 whatever route had previously been advertised by the peer or add a 1437 route if there was no previous route, in both cases adding a route 1438 with the current attributes. 1440 Don't put the same prefix in the same in both the withdraw and NLRI 1441 section of the same update. 1443 If you receive an UPDATE with the same prefix in both the withdraw 1444 and NLRI, ignore the withdraw. [Some older implementations thought 1445 this was a good way to say "delete then add".] 1447 Process UPDATEs from the same peer in the order received. 1449 And goes on to say, that to him, these rules are clear from the 1450 existing text. 1452 Consensus is that while this would be nice, we need to stick with 1453 what we have, and move on. 1455 2.24 Addition or Deletion of Path Attributes 1457 Status: Consensus 1458 Change: Yes 1459 Summary: Add the following to section 3.1: 1461 Changing the attributes of a route is accomplished by advertising a 1462 replacement route. The replacement route carries new (changed) 1463 attributes and has the same NLRI as the original route. 1465 Discussion: 1467 5. P. 20 Its not stated how we delete or modify Path Attributes 1468 associated with NLRI prefixes. 1470 A response to this comment said that this is implicit in the 1471 definition of "route" and the general withdraw/replace behavior and 1472 therefore doesn't need to be repeated. 1474 Ben responded saying that, while there was an assumption, there was 1475 no well defined mechanism, and this leads to ambiguity. 1477 John responded, no need to define everything explicitly, or we'll be 1478 here forever. 1480 Picking this thread up again, Yakov argued: 1482 By *definition* a route is a pair. From that 1483 definition it follows that changing one or more path attributes of a 1484 route means changing a route, which means withdrawing the old route 1485 (route with the old attributes) from service and advertising a new 1486 route (route with the new attributes). Procedures for doing this are 1487 well-defined (see section 3.1), and therefore no new text to cover 1488 this is needed. 1490 Jonathan agreed with this statement, but Ben argued that the text in 1491 section 3 is insufficient the way it is currently written. After 1492 two iterations, Ben and Yakov agreed on this formulation for an 1493 update to section 3.1: 1495 Changing the attributes of a route is accomplished by advertising a 1496 replacement route. The replacement route carries new (changed) 1497 attributes and has the same NLRI as the original route. 1499 Jeff objected somewhat to the wording, since, because of a bgp route 1500 is defined as a pair, changing either part of 1501 that pair, by definition, changes the route. He acknowledged that 1502 this might fall under the category of implementation detail. 1504 Yakov presented the view that he thought we were at consensus with 1505 the text he proposed above. Jonathan agreed. There were no 1506 objections, so this is moved to Consensus. 1508 2.25 NEXT_HOP Semantics 1510 Status: Consensus 1511 Change: No 1512 Summary: After responders pointed out another sentence, this comment 1513 was resolved. Things will stay the way they are. 1515 Discussion: 1517 1. P.28, 2nd to last paragraph. The line that reads, "To be 1518 semantically correct, the IP address in the NEXT_HOP must not be the 1519 IP address of the receiving speaker, and the NEXT_HOP IP address must 1520 either be the sender's IP address (used to establish the BGP 1521 session), or the interface associated with the NEXT_HOP IP address 1522 must share a common subnet with the receiving BGP speaker..." 1524 This is not always true, what if the current ASBR BGP router is 1525 advertising an external AS route (to a IBGP Peer) whose NEXT_HOP IP 1526 address is the IP address of the EBGP peer in the other AS? 1528 A response to this pointed out that right before this is a sentence 1529 stating that this only applied to eBGP links, and only when the peers 1530 are one hop from each other, so a modification is unnecessary. This 1531 response was confirmed with another. 1533 The original reviewer acknowledged this and withdrew the comment. 1535 The consensus is to leave things the way they are. 1537 2.26) Attributes with Multiple Prefixes 1539 Status: Consensus 1540 Change: No 1541 Summary: After some discussion, the consensus is to keep things the 1542 same since the suggested behavior is defined in the message format. 1544 Discussion: 1546 2. P. 29, Section 6.3. Add this rule near the attribute rules. 1547 "Multiple prefixes that require the same attribute type with 1548 different values must never appear in the same update message". 1550 A response to this suggested that this text is unnecessary since this 1551 behavior is ruled out by the way the message format is defined. 1553 The original commenter agrees with the responder. The consensus is 1554 to leave things the way they are. 1556 2.27 Allow All Non-Destructive Messages to Refresh Hold Timer 1558 Status: Consensus 1559 Change: No 1560 Summary: It is agreed that this is a change that exceeds the original 1561 goal of this draft revision. This goal is to document existing 1562 practice in an interoperable way. 1564 Discussion: 1566 3. P. 29, Section 6.5, Please rewrite this sentence from: "If a 1567 system does not receive successive KEEPALIVE and/or UPDATE and/or 1568 NOTIFICATION messages within the period specified in the Hold Time 1569 field of the OPEN message ..." 1571 To This: "If a system does not receive successive KEEPALIVE and/or 1572 UPDATE and/or any other BGP message within the period specified in 1573 the Hold Time field of the OPEN message ..." 1575 There is disagreement on this change. It has been discussed in other 1576 threads. 1578 The original commenter acknowledged that this is something that would 1579 be "adding a new feature" as opposed to the stated goal of 1580 "documenting what exists." He suggested that the ADs decide if we 1581 should open the door for new features or not. 1583 Yakov replied to this that he would suggest we keep things as is, 1584 since the purpose is to document current implementations. 1586 This did not meet with any objections, so this issue has been moved 1587 into consensus. 1589 2.28 BGP Identifier as Variable Quantity 1591 Status: Consensus 1592 Change: No 1593 Summary: The consensus is that changing the BGP Identifier in the 1594 base draft is out-of-scope at this point in the draft evolution. 1596 Discussion: 1598 4. P. 31, section 6.8, Please rewrite this sentence from: "Comparing 1599 BGP Identifiers is done by treating them as (4-octet long) unsigned 1600 integers." 1602 To This: "Comparing BGP Identifiers is done by treating them as large 1603 numbers based on their IP Address type (e.g. IPv4, IPv6, etc.)." 1605 A response to this was that since BGP Identifier is defined in the 1606 base spec as a 4 byte unsigned integer, and not a variable quantity, 1607 the sentence as written is acceptable. This was also confirmed by 1608 another response. 1610 The original commenter was thinking of IPv6, and providing sufficient 1611 space to allow a full v6 address to be used. 1613 Again, responders said that this is out-of-scope for the current 1614 draft. 1616 2.29 State Why Unresolveable Routes Should Be Kept in Adj-RIB-In 1618 Status: Consensus 1619 Change: Yes 1620 Summary: Add: 1622 "in case they become resolvable" after the last sentence on p. 46. 1624 Discussion: 1626 5. P.46, last sentence, "However, corresponding unresolvable routes 1627 SHOULD be kept in the Adj-RIBs-In." It would helpful if the author 1628 states why unresolvable routes should be kept in Adj-RIBs-In? 1630 A response to this stated "In case they become resolvable" 1632 Yakov responded that: 1634 I suggest we add "in case they become resolvable" after the last 1635 sentence on p. 46. 1637 The original commenter stated that: Then the point that the peer will 1638 not refresh the route if we drop them (unless we use Route Refresh) 1639 because they are unreachable should be made. 1641 Yakov also responded that: 1643 This should be clear from the following text in Section 3: 1645 The initial data flow is the portion of the BGP routing table that is 1646 allowed by the export policy, called the Adj-Ribs-Out (see 3.2). 1647 Incremental updates are sent as the routing tables change. BGP does 1648 not require periodic refresh of the routing table. 1650 Jonathan, who was the original commenter, agreed with both the 1651 changed text and the clarity of section 3. 1653 2.30 Mention Other Message Types 1655 Status: Consensus 1656 Change: Yes 1657 Summary: Add a reference to RFC2918 at the end of the type code list. 1659 Discussion: 1661 1. P. 7 Type: Need to add the new message types such as, Capability 1662 Negotiations (RFC2842), Route Refresh, etc. 1664 One response argued that these are out-of-scope of the base document. 1665 One response agreed, but thought that it should be capability and not 1666 message type. The original commenter responded about Message type 1667 from the capability draft. 1669 Sue mentioned this would be added in the second round. 1671 Yakov replied that: 1673 The only new message type that is covered by an RFC (rather than just 1674 an Internet Draft) is the Refresh message. With this in mind how 1675 about replacing the following: 1677 The following type codes are defined: 1679 1 - OPEN 1680 2 - UPDATE 1681 3 - NOTIFICATION 1682 4 - KEEPALIVE 1684 with 1686 This document defines the following type codes: 1688 1 - OPEN 1689 2 - UPDATE 1690 3 - NOTIFICATION 1691 4 - KEEPALIVE 1693 [RFC2918] defines one more type code. 1695 Jonathan agreed with this change. This issue has been moved to 1696 consensus. 1698 2.31 Add References to Additional Options 1700 Status: Consensus 1701 Change: Yes 1702 Summary: Consensus to add: 1704 [RFC2842] defines another Optional Parameter. 1706 Discussion: 1708 2. P. 9, right after "This document defines the following optional 1709 parameters:" Need to mention possible options, such as: Capabilities 1710 (RFC2842), Multiprotocol extensions (RFC2858), Route Refresh 1711 (RFC2918). 1713 One response agreed that adding references would be fine. A second 1714 response agreed. 1716 Yakov replied that: 1718 Please note that only rfc2842 defines an OPEN optional parameter. 1719 Neither rfc2858 nor rfc2918 defines an OPEN optional parameter. 1721 With this in mind I would suggest to add the following text: 1723 [RFC2842] defines another Optional Parameter. 1725 The original poster agreed with this modification. This issue is at 1726 consensus. 1728 2.32 Clarify EGP Reference 1729 Status: Consensus 1730 Change: No 1731 Summary: The consensus is that this was addressed in 32.1, so we can 1732 close this. 1734 Discussion: 1736 3. P. 13, EGP, are there other EGP protocols other than BGP that are 1737 in use? If not, change EGP to BGP. 1739 A response to this suggested that we add a reference to [1] (the EGP 1740 spec) here. 1742 Another response clarified that this refers to EGP-the-protocol and 1743 NOT the class. 1745 Another response disagreed, but suggested that: 1747 IGP = network was explicitly introduced into bgp (network cmd) 1748 INCOMPLETE = network was implicitly introduced into bgp 1749 (redistribute) EGP = other 1751 The original commenter thought that this referred to EGP-the-class of 1752 protocols. And why not use BGP therefore, as the only EGP. 1754 There was some discussion over whether or not we should mention 1755 something that is historical. 1757 Jeff suggested a footnote in the Origin section about EGP. 1759 Curtis suggested that we state that the EGP in ORIGIN is deprecated, 1760 but retain the value to document what it used to mean. 1762 This reviewer thinks a statement about whether this "EGP" origin 1763 refers to the protocol or the class or protocols would be useful. 1765 Yakov replied that an EGP reference will be added (see issue 9). 1767 Yakov also stated that he doesn't see what is wrong with the current 1768 text, and suggested we keep it. This includes leaving out any 1769 reference to the status of the EGP spec. He sees that it is clear 1770 from context that we are talking about "the EGP" [RFC904]. 1772 Jeff noted that this issue has been sufficiently addressed in the 1773 solution to 32.1. This met with agreement. We are at consensus. 1775 2.32.1 EGP ORIGIN Clarification 1776 Status: Consensus 1777 Change: Yes 1778 Summary: Change section 5.1.1 to read: 1780 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1781 shall be generated by the speaker that originates the associated 1782 routing information. Its value SHOULD NOT be changed by any other 1783 speaker." 1785 Consensus to change: 1787 1 EGP - Network Layer Reachability Information 1788 learned via the EGP protocol 1790 to: 1792 1 EGP - Network Layer Reachability Information 1793 learned via the EGP protocol [RFC904] 1795 Discussion: 1797 This discussion is picked up again in the "Review of draft-ietf-idr- 1798 bgp4-17" thread, where specific text is proposed: 1800 Old: 1802 "ORIGIN is a well-known mandatory attribute that defines the 1803 origin of the path information. The data octet can assume 1804 the following values: 1806 Value Meaning 1808 0 IGP - Network Layer Reachability Information 1809 is interior to the originating AS 1811 1 EGP - Network Layer Reachability Information 1812 learned via the EGP protocol 1814 2 INCOMPLETE - Network Layer Reachability 1815 Information learned by some other means" New: 1817 "ORIGIN is a well-known mandatory attribute that defines the 1818 origin of the path information. The data octet can assume 1819 the following values: 1821 Value Meaning 1822 0 IGP - NLRI was explicitly introduced into bgp 1824 1 EGP - this value was administratively 1825 configured to affect policy decisions or NLRI was 1826 learned via the EGP protocol [1] 1828 2 INCOMPLETE - NLRI was implicitly introduced 1829 into bgp" 1831 since: 1) The network command sets the origin to IGP and I remember 1832 seeing somewhere that only static routes should be set to IGP. 2) 1833 The primary use of EGP value is policy 3) EGP seems to still exist, 1834 anyway even if it does not it is not worth re-writing the world. 1836 Also, change: "5.1.1 ORIGIN 1838 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1839 shall be generated by the autonomous system that originates the 1840 associated routing information. It shall be included in the UPDATE 1841 messages of all BGP speakers that choose to propagate this 1842 information to other BGP speakers." 1844 to: "5.1.1 ORIGIN 1846 The value of the ORIGIN attribute shall be set by the speaker that 1847 originates the associated NLRI. Its value shall not be changed 1848 by any other speaker unless the other speaker is administratively 1849 configured to do so to affect policy decisions." 1851 since: 1) It is already defined as well-known mandatory attribute. 1852 2) It may be set differently within the same AS (not saying this is 1853 good). 3) It is commonly used for policy, but by default does not 1854 get changed. 4) Speakers have no choice, it is mandatory. 1856 After much continued discussion on this in the "issue 32.1" thread, 1857 we seem to have come to a consensus that section 5.1.1 should read: 1859 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1860 shall be generated by the speaker that originates the associated 1861 routing information. Its value should not be changed by any other 1862 speaker unless the other speaker is administratively configured to do 1863 so to affect policy decisions." 1865 This text met with a number of agreements, and one disagreement 1866 stating that we shouldn't have the "unless administratively 1867 configured" portion. 1869 After some further discussion, we have this text on the table: 1871 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1872 generated by the BGP speaker that originates the associated BGP 1873 routing information. The attribute shall be included in the UPDATE 1874 messages of all BGP speakers that choose to propagate this 1875 information to other BGP speakers. 1877 Jonathan suggested that we change "propagate this information" to 1878 "forward this route". He also mentioned that he would prefer 1879 something more explicit instead of/in addition to "The attribute 1880 shall be included in the UPDATE messages of all BGP speakers that 1881 choose to propagate this information to other BGP speakers." such as 1882 "other speakers do not change the ORIGIN value." 1884 On the issue of making the EGP ORIGIN type more clear Andrew 1885 proposed: 1887 To me, there seems to be sufficient confusion around the "EGP" 1888 reference to merit some sort of clarification. The simplest 1889 modification would be to change: 1891 1 EGP - Network Layer Reachability Information 1892 learned via the EGP protocol 1894 to: 1896 1 EGP - Network Layer Reachability Information 1897 learned via the EGP protocol [RFC904] 1899 That would clarify that we're talking about the protocol, and not the 1900 class-of-protocols, or EBGP. It would leave unstated that this could 1901 theoretically be used to muck with route selection. I think that is 1902 ok. If operators want to override ORIGIN to affect some hoho magic, 1903 they are welcome to do so, but I don't think it needs to be 1904 documented in the base spec. 1906 This met with a number of agreements. 1908 On the second text section we are working on, Jonathan objected to 1909 the current working text below and suggested an alternate: 1911 CHANGE: 1913 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1914 generated by the BGP speaker that originates the associated BGP 1915 routing information. The attribute shall be included in the UPDATE 1916 messages of all BGP speakers that choose to propagate this 1917 information to other BGP speakers." 1919 TO: 1921 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1922 shall be generated by the speaker that originates the associated 1923 routing information. Its value should not be changed by any other 1924 speaker unless the other speaker is administratively configured to do 1925 so to affect policy decisions." 1927 -or- 1929 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1930 shall be generated by the speaker that originates the associated 1931 routing information. Its value should not be changed by any other 1932 speaker." 1934 Jonathan cited a recent example of someone who was still confused by 1935 this section of the text in -17 (not specifically the working text). 1937 Yakov proposed this as final text: 1939 In 4.3: 1941 a) ORIGIN (Type Code 1): 1943 ORIGIN is a well-known mandatory attribute that defines the origin of 1944 the path information. The data octet can assume the following 1945 values: 1947 Value Meaning 1949 0 IGP - Network Layer Reachability Information 1950 is interior to the originating AS 1952 1 EGP - Network Layer Reachability Information 1953 learned via the EGP protocol [RFC904] 1955 2 INCOMPLETE - Network Layer Reachability 1956 Information learned by some other means 1958 Usage of this attribute is defined in 5.1.1. 1960 In 5.1.1: 1962 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1963 shall be generated by the speaker that originates the associated 1964 routing information. Its value SHOULD NOT be changed by any other 1965 speaker." 1967 This met with agreement. This issue is at consensus. 1969 2.32.2 BGP Destination-based Forwarding Paradigm 1971 Status: Consensus 1972 Change: Yes 1973 Summary: After much discussion, this is the consensus: This text in 1974 the current draft: 1976 To characterize the set of policy decisions that can be enforced 1977 using BGP, one must focus on the rule that a BGP speaker advertises 1978 to its peers (other BGP speakers which it communicates with) in 1979 neighboring ASs only those routes that it itself uses. This rule 1980 reflects the "hop-by-hop" routing paradigm generally used throughout 1981 the current Internet. Note that some policies cannot be supported by 1982 the "hop-by-hop" routing paradigm and thus require techniques such as 1983 source routing (aka explicit routing) to enforce. For example, BGP 1984 does not enable one AS to send traffic to a neighboring AS intending 1985 that the traffic take a different route from that taken by traffic 1986 originating in the neighboring AS. On the other hand, BGP can support 1987 any policy conforming to the "hop-by-hop" routing paradigm. Since the 1988 current Internet uses only the "hop-by-hop" inter-AS routing paradigm 1989 and since BGP can support any policy that conforms to that paradigm, 1990 BGP is highly applicable as an inter-AS routing protocol for the 1991 current Internet. 1993 will be replaced in -18 with the following text: 1995 Routing information exchanged via BGP supports only the destination- 1996 based forwarding paradigm, which assumes that a router forwards a 1997 packet based solely on the destination address carried in the IP 1998 header of the packet. This, in turn, reflects the set of policy 1999 decisions that can (and can not) be enforced using BGP. Note that 2000 some policies cannot be supported by the destination-based forwarding 2001 paradigm, and thus require techniques such as source routing (aka 2002 explicit routing) to be enforced*. Such policies can not be enforced 2003 using BGP either. For example, BGP does not enable one AS to send 2004 traffic to a neighboring AS for forwarding to some destination 2005 (reachable through but) beyond that neighboring AS intending that the 2006 traffic take a different route to that taken by the traffic 2007 originating in the neighboring AS (for that same destination). On 2008 the other hand, BGP can support any policy conforming to the 2009 destination-based forwarding paradigm. 2011 Discussion: 2013 In response to these proposals, Yakov proposed that the real problem 2014 is that it is not clear that BGP is build to support the destination- 2015 based forwarding paradigm. To fix this, it was proposed that: 2017 2019 To characterize the set of policy decisions that can be enforced 2020 using BGP, one must focus on the rule that a BGP speaker advertises 2021 to its peers (other BGP speakers which it communicates with) in 2022 neighboring ASs only those routes that it itself uses. This rule 2023 reflects the "hop-by-hop" routing paradigm generally used throughout 2024 the current Internet. Note that some policies cannot be supported by 2025 the "hop-by-hop" routing paradigm and thus require techniques such as 2026 source routing (aka explicit routing) to enforce. For example, BGP 2027 does not enable one AS to send traffic to a neighboring AS intending 2028 that the traffic take a different route from that taken by traffic 2029 originating in the neighboring AS. On the other hand, BGP can support 2030 any policy conforming to the "hop-by-hop" routing paradigm. Since the 2031 current Internet uses only the "hop-by-hop" inter-AS routing paradigm 2032 and since BGP can support any policy that conforms to that paradigm, 2033 BGP is highly applicable as an inter-AS routing protocol for the 2034 current Internet. 2036 2038 Routing information exchanged via BGP supports only the destination- 2039 based forwarding paradigm, which assumes that a router forwards a 2040 packet based solely on the destination address carried in the IP 2041 header of the packet. This, in turn reflects the set of policy 2042 decisions that can (and can not) be enforced using BGP. Note that 2043 some policies cannot be supported by the destination-based forwarding 2044 paradigm and thus require techniques such as source routing (aka 2045 explicit routing) to enforce. Such policies can not be enforced using 2046 BGP either. For example, BGP does not enable one AS to send traffic 2047 to a neighboring AS intending that the traffic take a different route 2048 from that taken by traffic originating in the neighboring AS. On 2049 the other hand, BGP can support any policy conforming to the 2050 destination-based forwarding paradigm. 2052 Curtis thinks the newer text here is more clear. 2054 In response to the new text, Christian Martin proposed a slightly 2055 different new text: 2057 Routing information exchanged via BGP supports only the destination- 2058 based forwarding paradigm, which assumes that a router forwards a 2059 packet based solely on the destination address carried in the IP 2060 header of the packet. This, in turn reflects the set of policy 2061 decisions that can (and can not) be enforces using BGP. Note that 2062 some policies cannot be supported by the destination-based forwarding 2063 paradigm and thus require techniques such as source routing (aka 2064 explicit routing) to enforce. Such policies can not be enforced using 2065 BGP either. For example, BGP does not enable one AS to send traffic 2066 to a neighboring AS based on prefixes originating from the local AS. 2067 On the other hand, BGP can support any policy conforming to the 2068 destination-based forwarding paradigm. 2070 To which Yakov replied: 2072 Routing information exchanged via BGP supports only the destination- 2073 based forwarding paradigm, which assumes that a router forwards a 2074 packet based solely on the destination address carried in the IP 2075 header of the packet. This, in turn, reflects the set of policy 2076 decisions that can (and can not) be enforces using BGP. Note that 2077 some policies cannot be supported by the destination-based forwarding 2078 paradigm, and thus require techniques such as source routing (aka 2079 explicit routing) to enforce. Such policies can not be enforced using 2080 BGP either. For example, BGP does not enable one AS to send traffic 2081 through a neighboring AS to some destination (which is outside of the 2082 neighboring AS, but is reachable through the neighboring AS) 2083 intending that the traffic take a different route from that taken by 2084 the traffic to the same destination that originating in the 2085 neighboring AS. On the other hand, BGP can support any policy 2086 conforming to the destination-based forwarding paradigm. 2088 And Chris responded: 2090 Routing information exchanged via BGP supports only the destination- 2091 based forwarding paradigm, which assumes that a router forwards a 2092 packet based solely on the destination address carried in the IP 2093 header of the packet. This, in turn, reflects the set of policy 2094 decisions that can (and can not) be enforces using BGP. Note that 2095 some policies cannot be supported by the destination-based forwarding 2096 paradigm, and thus require techniques such as source routing (aka 2097 explicit routing) to enforce. Such policies can not be enforced using 2098 BGP either. For example, BGP does not enable one AS to send traffic 2099 through a neighboring AS to some destination beyond the neighboring 2100 AS intending that the traffic take a different route from that taken 2101 by traffic to the same destination which originates in the 2102 neighboring AS. In other words, the BGP policy of a local AS cannot 2103 affect the downstream (aka, away from the local AS) forwarding policy 2104 of a remote AS. On the other hand, BGP can support any policy 2105 conforming to the destination-based forwarding paradigm. 2107 Tom Petch preferred Yakov's second formulation, with these changes: 2109 policies can not be enforced using BGP either. For example, BGP does 2110 not enable one AS to send traffic ! to a neighboring AS for 2111 forwarding to some destination (reachable through but) beyond ! 2112 that neighboring AS intending that ! the traffic take a different 2113 route to that taken by the traffic ! originating in the 2114 neighboring AS (for that same destination). 2116 On the other hand, BGP can support any policy conforming to the 2117 destination-based forwarding paradigm. 2119 Yakov agreed to Tom's suggested changes. 2121 2.33 Add "Optional Non-Transitive" to the MED Section 2123 Status: Consensus 2124 Change: Yes 2125 Summary: Add "Optional Non-Transitive" to MED Section 2126 Add "well-known mandatory" to the NEXT_HOP Section 2128 Discussion: 2130 4. P.23, change the following: 2132 "The MULTI_EXIT_DISC attribute may be used on external (inter-AS) 2133 links to discriminate among multiple exit or entry points to the same 2134 neighboring AS ..." 2136 To the following: 2138 "The MULTI_EXIT_DISC is an optional non-transitive attribute which 2139 may be used on external (inter-AS) links to discriminate among 2140 multiple exit or entry points to the same neighboring AS ..." 2142 A responder disagreed, and stated reasons "covered elsewhere" 2143 Original commenter asked for reasons, since the modification seemed 2144 obvious to him. 2146 Yakov agreed to make this change in -18. 2148 Jonathan replied that: 2150 5.1.3 NEXT_HOP also, it is missing " well-known mandatory". 2152 Yakov also agreed to make this change. 2154 2.34 Timer & Counter Definition 2156 Status: Consensus 2157 Change: No 2158 Summary: No discussion, no text proposed, defaults to consensus for 2159 no change. 2161 Discussion: 2163 5. In section 8, there are a number of Timers, Counters, etc. that 2164 need to be explicitly defined before they are used by the FSM. 2165 Perhaps these definitions should go in the Glossary section. 2167 There has been no further discussion on this issue. Unless it is 2168 brought up again, this issue is in consensus, with no change. 2170 2.35 Fix Typo 2172 Status: Consensus 2173 Change: Yes 2174 Summary: Fix a Typo. No discussion, but this seem clear. 2176 Discussion: 2178 1. P. 41. Typing error, "Each time time the local system...". 2180 2.36 Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 2182 Status: Consensus 2183 Change: Yes 2184 Summary: This change requires a glossary. Yakov has committed to 2185 having a section where commonly used terms are defined in draft 18, 2186 so this issue is at consensus. 2188 Discussion: 2190 2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in 2191 the glossary, so when they are used in section 9.1, it is well 2192 understood what they are. 2194 Yakov replied: 2196 will be added to the section "Definition of commonly used terms" in 2197 -18 version. 2199 2.37 Combine "Unfeasible Routes" and "Withdrawn Routes" 2201 Status: Consensus 2202 Change: Yes 2203 Summary: Add the following terms to the "commonly used terms 2204 section": 2206 Feasible route A route that is available for use. 2208 Unfeasible route A previously advertised feasible route that is no 2209 longer available for use. 2211 Discussion: 2213 3. P. 45, Phase I, There is no definition of what are unfeasible 2214 routes? Are they the same as withdrawn routes? If so, the two should 2215 be combined to one name. 2217 Ishi replied to this that he thought that we could combine the two 2218 terms, since there is limited difference from an implementation 2219 standpoint. 2221 Yakov replied: 2223 The routes are withdrawn from service because they are unfeasible, 2224 not because they are "withdrawn". So, we need to keep the term 2225 "unfeasible" to indicate the *reason* why a route could be withdrawn. 2226 On the other hand, "withdrawn" is used as a verb, and to the best of 2227 my knowledge "unfeasible" can't be used as a verb. With this in 2228 mind, I don't think that we can combine the two into a single term. 2230 Ishi replied that he was convinced, and that the terms should stay 2231 separate. 2233 Andrew asked the list if we should define these terms in the 2234 "commonly used terms" section in draft -18. 2236 Ben replied that if we use them a lot, we should define them, and if 2237 not local definitions will suffice. 2239 There was some back and forth about the necessity of defining terms 2240 which should be obvious. 2242 mrr actually checked the doc to see if we were consistently using the 2243 terms, and found: 2245 It turns out there there is an inconsistency in the usage of the word 2246 withdrawn. 2248 Section 3.1: 2250 There are three methods by which a given BGP speaker can indicate 2251 that a route has been withdrawn from service: 2253 ... 2255 b) a replacement route with the same NLRI can be advertised, or 2257 ... 2259 Later, in the definition of Withdrawn Routes Length, we have: 2261 A value of 0 indicates that no routes are being withdrawn from 2262 service, 2264 Taken together, this could be construed as meaning that a Withdrawn 2265 Routes Length of 0 indicates that all routes included in the UPDATE 2266 represent newly feasible routes... not replacement routes. 2268 Now, it's possible that this problem has been removed by changes to 2269 the text that have not yet been incorporated in to a new draft; 2270 however, it arose because the text, for the most part, does _not_ use 2271 "withdrawn" in the standard way. Instead, it refers to routes 2272 included in the WITHDRAWN ROUTES field of an UPDATE message. 2273 Consequently, I propose defining a "withdrawn route" as follows: 2275 Withdrawn route: a route included in the WITHDRAW ROUTES field of an 2276 UPDATE message. 2278 Regardless of whether or not this definition is included, Section 3.1 2279 should be changed from: 2281 There are three methods by which a given BGP speaker can indicate 2282 that a route has been withdrawn from service: 2284 to: 2286 There are three methods by which a given BGP speaker can indicate 2287 that a route has been removed from service: 2289 or: 2291 There are three methods by which a given BGP speaker can indicate 2292 that a route is now unfeasible: 2294 After some further off-list discussion, mrr agreed that this 2295 inconsistency is extremely minor, and withdrew his comment. feasible 2296 and unfeasible route will be defined in the "commonly used terms" 2297 section to clear up any confusion. 2299 2.38 Clarify Outbound Route Text 2301 Status: Consensus 2302 Change: No 2303 Summary: Consensus that the issue was sufficiently minor to leave 2304 things alone. 2306 Discussion: 2308 4. P. 50, line, "If a route in Loc-RIB is excluded from a particular 2309 Adj-RIB-Out the previously advertised route in that Adj-RIB-Out must 2310 be withdrawn from service by means of an UPDATE message (see 9.2)." 2312 Would like to rephrase the sentence for clarity, "If a route in Loc- 2313 RIB is excluded from a particular Adj-RIB-Out and was previously 2314 advertised via Adj-RIB-Out, it must be withdrawn from service by 2315 means of an UPDATE message (see 9.2)." 2317 One comment suggested either leave it alone, or remove "via Adj-RIB- 2318 Out". 2320 The original commenter withdrew the comment. 2322 2.39 Redundant Sentence Fragments 2324 Status: Consensus 2325 Change: Yes 2326 Summary: Fix typo & parentheses. 2328 Discussion: 2330 5. P. 50, section 9.1.4, The two fragments of this sentence are 2331 redundant and don't say anything new or simplify the content. Just 2332 keep one fragment. 2334 "A route describing a smaller set of destinations (a longer prefix) 2335 is said to be more specific than a route describing a larger set of 2336 destinations (a shorted prefix); similarly, a route describing a 2337 larger set of destinations (a shorter prefix) is said to be less 2338 specific than a route describing a smaller set of destinations (a 2339 longer prefix)." 2341 There was a comment that disagreed, thinking that both "more 2342 specific" and "less specific" need to be defined. And suggested that 2343 only the third and forth parentheses need to be dropped. 2345 The original commenter agreed with the parentheses changes. 2347 Yakov agreed to drop the third and fourth parentheses in the -18 2348 version. 2350 Jonathan replied to this: 2352 Disagree, the text if fine the way it is, except you need to change 2353 "shorted" to "shorter". 2355 After minimal further discussion, it was decided we are at a 2356 consensus on this issue to fix the typo and drop the third and fourth 2357 parentheses. 2359 2.40 Section 9.2.1.1 - Per Peer vs. Per Router 2360 MinRouteAdvertisementInterval 2362 Status: Consensus 2363 Change: No 2364 Summary: The consensus is that current practice allows for the 2365 MinRouteAdvertisementInterval to be set per peer, so the text should 2366 be kept the same. 2368 Discussion: 2370 6. P. 52, section 9.2.1.1 Change this sentence for clarity, "This 2371 rate limiting procedure applies on a per-destination basis, although 2372 the value of MinRouteAdvertisementInterval is set on a per BGP peer 2373 basis." 2375 To This: "This rate limiting procedure applies on a per-destination 2376 basis, although the value of MinRouteAdvertisementInterval is set on 2377 a BGP router (same value for all peers) basis." 2379 There was a comment disagreeing with this proposal. It was later 2380 elaborated on to include that the reason for disagreement was that 2381 the proposed changes changed the protocol and not just a practice 2382 clarification. Ben responded asking for how this is a protocol 2383 change, he saw it as a clarification. Perhaps there is something 2384 deeper that needs to be clarified? Again, response to this is that 2385 current implementations allow the MinRouteAdvertisementInterval to be 2386 set per-peer, not per-router. 2388 Original reviewer conceded the point. 2390 There was some additional discussion on this point. Most of it was 2391 along the lines of extracting what was really implemented and 2392 supported among various vendors. The conclusion was the same. 2394 2.41 Mention FSM Internal Timers 2396 Status: Consensus 2397 Change: No 2398 Summary: No discussion on this issue. No text proposed. Perhaps 2399 this is in the FSM section of the draft? Either way, it defaults to 2400 consensus with no change. 2402 Discussion: 2404 7. P. 61, item 6.4. Although all the BGP protocol interfacing timers 2405 are mentioned, there are a few FSM internal timers mentioned in the 2406 spec that need to be covered here as well. 2408 There has been no discussion on this, it now defaults to consensus 2409 with no change. 2411 2.42 Delete the FSM Section 2413 Status: Consensus 2414 Change: No 2415 Summary: There was some confusion on the question: Is the FSM draft 2416 going to be a separate document, or incorporated into the base draft. 2417 The consensus is that it is going to become part of the base draft, 2418 so the FSM section will be kept, and elaborated on. 2420 Discussion: 2422 8. Since there is going to be an FSM spec, do we need to have FSM 2423 descriptions in this spec. Maybe the FSM section should be delete. 2425 There was one response agreeing with this. One response asking for 2426 clarification: Was this a move to remove section 8. Finite State 2427 Machine from the base draft?? The original reviewer said, yes, when 2428 Sue's FSM draft becomes a WG document, we should remove section 8 2429 from the base draft. Yakov asked that the AD's provide input on this 2430 suggestion. 2432 Alex responded saying that the FSM draft is going to be part of the 2433 base spec, and not another document once the FSM words are approved. 2435 2.43 Clarify the NOTIFICATION Section 2437 Status: Consensus 2438 Change: Yes 2439 Summary: Replace: 2441 "If a peer sends a NOTIFICATION message, and there is an error in 2442 that message, there is unfortunately no means of reporting this error 2443 via a subsequent NOTIFICATION message." 2445 With: 2447 If a peer sends a NOTIFICATION message, and the receiver of the 2448 message detects an error in that message, the receiver can not use a 2449 NOTIFICATION message to report this error back to the peer. 2451 Discussion: 2453 The "NOTIFICATION message error handling" thread proposed: 2455 Please change" "If a peer sends a NOTIFICATION message, and there is 2456 an error in that message, there is unfortunately no means of 2457 reporting this error via a subsequent NOTIFICATION message." 2459 To: "If a peer receives a NOTIFICATION message, and there is an error 2460 in that message, there is unfortunately no means of reporting this 2461 error via a subsequent NOTIFICATION message." 2463 This reversal of meaning met with disagreement, and this text was 2464 proposed instead: 2466 All errors detected while processing the NOTIFICATION message cannot 2467 be indicated by sending subsequent NOTIFICATION message back to 2468 originating peer, therefore there is no means of reporting 2469 NOTIFICATION message processing errors. Any error, such as an 2470 unrecognized Error Code or Error Subcode, should be noticed, logged 2471 locally, and brought to the attention of the administration of the 2472 peer that has sent the message. The means to do this, however, lies 2473 outside the scope of this document. 2475 The original posted agreed with the intent of the respondent's text, 2476 thought it was too wordy, but did not propose alternate text. 2478 Yakov replied with this proposed text: 2480 If a peer sends a NOTIFICATION message, and the receiver of the 2481 message detects an error in that message, the receiver can not use a 2482 NOTIFICATION message to report this error back to the peer. 2484 Two responses liked this new text. Unless there are objections, 2485 we'll consider that a consensus. 2487 2.44 Section 6.2: OPEN message error handling 2489 Status: Consensus 2490 Change: No 2491 Summary: One commenter observed that the spec seems to specify 2492 behavior that doesn't seem to be observed by extant implementations, 2493 and suggested modifications to the spec. They were later reminded 2494 that the base behavior is acceptable, and agreed. 2496 Discussion: 2498 The "BGP4 draft ; section 6.2" thread began with a discussion of 2499 section 6.2: OPEN message error handling. Specifically: 2501 "If one of the optional parameters in the Open message is not 2502 recognized, then the error subcode is set to 'unsupported optional 2503 parameters" 2505 We have hit on this line when we were testing a BGP connection 2506 between a speaker that supported capability negotiation and a speaker 2507 that did not. 2509 The speaker that did not support the negotiation closed down the 2510 peering session using the error clause mentioned above. Sometimes 2511 this lead to the other router to repeat the OPEN message with the 2512 Capability optional parameter; a game that went on for minutes. 2514 This router manufacturer stated in a reply to this that : "One should 2515 not close down the connection if an optional parameter is 2516 unrecognized. That would make this parameter basically mandatory. 2517 This is an well known error in the BGP spec. Neither Cisco or Juniper 2518 do this" 2520 If this is true it might be good to adapt the text. 2522 The response to this quoted RFC2842, Capabilities Advertisement with 2523 BGP-4: 2525 A BGP speaker determines that its peer doesn't support capabilities 2526 advertisement, if in response to an OPEN message that carries the 2527 Capabilities Optional Parameter, the speaker receives a NOTIFICATION 2528 message with the Error Subcode set to Unsupported Optional Parameter. 2529 In this case the speaker should attempt to re-establish a BGP 2530 connection with the peer without sending to the peer the Capabilities 2531 Optional Parameter. 2533 The original poster responded: 2535 This section from the Capabilities Advertisement RFC, is indeed 2536 inline with the section 6.2 of the BGP4 specification. For me however 2537 the question remains if most implementations do no simply ignore 2538 optional parameters that are unknown. And if so, if the text stated 2539 above reflects what is implemented by routers that do not have 2540 capability advertisement at all. 2542 Yakov replied to this with: 2544 RFC2842 assumes that a router (that doesn't implement RFC2842) would 2545 close the BGP session when the router receives an OPEN message with 2546 an unrecognized Optional Parameter. Therefore the text in the spec 2547 should be left unmodified. 2549 The original poster, Jonathan, agreed with this. This issue moves to 2550 consensus. 2552 2.45 Consistent References to BGP Peers/Connections/Sessions 2554 Status: Consensus 2555 Change: Yes 2556 Summary: Stick with "BGP Connection" as the consistent term. 2558 Discussion: 2560 Ben proposed and Yakov responded: 2562 > 1. Throughout the document we have various ways of naming the BGP > 2563 peering communication. 1) BGP Session, 2) BGP Peering Session, 2565 I'll replace "session" with "connection". 2567 > 3) TCP Connection, 2569 The spec doesn't name BGP peering communication as "TCP connection"; 2570 TCP connection is used to establish BGP connection. So, TCP 2571 connection and BGP connection are two different things. 2573 > 4) BGP Connection, 2575 The spec is going to use this term (see above). 2577 > 5) BGP Peering Connection, 2579 I'll replace "BGP peering connection" with "BGP connection". 2581 > 6) Connection, 2583 The text uses "connection" whenever it is clear from the context that 2584 it refers to "BGP connection" (or "TCP connection"). 2586 > 7) BGP Speaker Connection. 2588 I'll replace "BGP Speaker Connection" with "BGP connection". 2590 > > BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker 2591 The term "speaker" is used when it is clear from the context that we 2592 are talking about "BGP speaker". 2594 > 2. Change Internal peer to IBGP Peer. 2596 IBGP stands for "BGP connection between internal peers". Therefore 2597 the term "IBGP Peer" would mean "BGP connection between internal 2598 peers peer". That doesn't seem appropriate. 2600 This issue has had some discussion, and section 3 was referenced, 2601 specifically: 2603 Refer to Section 3 - Summary of operations which clearly states that 2604 " .. a peer in a different AS is referred to as an external peer, 2605 while a peer in the same AS may be described as an internal peer. 2606 Internal BGP and external BGP are commonly abbreviated IBGP and EBGP" 2608 After more discussion it was decided that we should modify a 2609 paragraph on page 4 to read: 2611 If a particular AS has multiple BGP speakers and is providing transit 2612 service for other ASs, then care must be taken to ensure a consistent 2613 view of routing within the AS. A consistent view of the interior 2614 routes of the AS is provided by the IGP used within the AS. For the 2615 purpose of this document, it is assumed that a consistent view of the 2616 routes exterior to the AS is provided by having all BGP speakers 2617 within the AS maintain IBGP with each other. Care must be taken to 2618 ensure that the interior routers have all been updated with transit 2619 information before the BGP speakers announce to other ASs that 2620 transit service is being provided. 2622 This change has consensus. 2624 > 3. Change External peer to EBGP Peer. 2626 Ditto. 2628 Alex responded that having explicit definitions would be nice. This 2629 ties into the general glossary suggestion (see issues 16, 34 & 36). 2631 He also suggested that: 2633 "BGP session" which works over a "TCP connection" would be closer to 2634 the terminology we're actually using now and would avoid possible 2635 confusions when people read terms like "Connection collision") 2637 This was discussed in the "Generial Editorial Comment" thread. 2639 After some further discussion, it was decided that, due to existing 2640 implementations, we should go with "BGP connection" as the consistent 2641 term. We are at consensus. 2643 2.46 FSM Connection Collision Detection 2645 Status: Consensus 2646 Change: Yes 2647 Summary: Add this to section 8: 2649 There is one FSM per connection. Prior to determining what peer a 2650 connection is associated with there may be two connections for a 2651 given peer. There should be no more than one connection per peer. 2652 The collision detection identifies the case where there is more than 2653 one connection per peer and provides guidance for which connection to 2654 get rid of. When this occurs, the corresponding FSM for the 2655 connection that is closed should be disposed of. 2657 Discussion: 2659 The original reviewer (Tom) commented that the base draft, FSM 2660 section, could use some clarification around the area of connection 2661 collision detection. Specifically, he argued that it seems like 2662 there are actually 2 FSM's depending on which one backs off in the 2663 case of a collision. He proposed this text to clear things up: 2665 "8 BGP Finite State Machine 2667 This section specifies BGP operation - between a BGP speaker and its 2668 peer over a single TCP connection - in terms of a Finite State 2669 Machine (FSM). Following is a brief summary ... "(as before) 2671 Instead of just 2673 "This section specifies BGP operation in terms of a Finite State 2674 Machine (FSM). Following is a brief summary ... "(as before). 2676 Curtis responded: 2678 There is one FSM per connection. Prior to determining what peer a 2679 connection is associated with there may be two connections for a 2680 given peer. There should be no more than one connection per peer. 2681 The collision detection identifies the case where there is more than 2682 one connection per peer and provides guidance for which connection to 2683 get rid of. When this occurs, the corresponding FSM for the 2684 connection that is closed should be disposed of. 2686 I'm not sure which document containing an FSM we should be reading at 2687 this point, but we could add the above paragraph if we need to 2688 explicitly state that the extra connection and its FSM is disposed of 2689 when a collision is detected. 2691 When a TCP accept occurs, a connection is created and an FSM is 2692 created. Prior to the point where the peer associated with the 2693 connection is known the FSM cannot be associated with a peer. The 2694 collision is a transient condition in which the rule of "one BGP 2695 session per peer" is temporarily violated and then corrected. 2697 This is discussed in the "FSM but FSM of what?" thread. 2699 Sue responded that she would be happy to add Curtis' text to section 2700 8 and solicited any additional comments. There was only one on 2701 capitalization, so this issue is at consensus. 2703 2.47 FSM - Add Explicit State Change Wording 2705 Status: Consensus 2706 Change: No 2707 Summary: A desire for explicit state change wording was expressed. 2708 No text was proposed. The assumption is that this issue has reached 2709 a happy conclusion. 2711 Discussion: 2713 The initial reviewer: 2715 In most places, the actions taken on the receipt of an event include 2716 what the new state will be or that it remains unchanged. But there 2717 are a significant number of places where this is not done (eg Connect 2718 state events 14, 15, 16). I would like to see consistency, always 2719 specify the new/unchanged state. Else I may be misreading it. 2721 There was a response asking for specific text, and offering to take 2722 the discussion private. 2724 This is discussed in the "FSM words - state changes" thread. 2726 There has been no further discussion on this. The assumption is that 2727 is has reached a happy conclusion privately. 2729 2.48 Explicitly Define Processing of Incoming Connections 2731 Status: Consensus 2732 Change: Yes 2733 Summary: Add text that is at the end of the discussion to section 8. 2735 Discussion: 2737 Alex suggested we explicitly define: 2739 - processing of incoming TCP connections (peer lookup, acceptance, 2740 FSM creation, collision control,) 2742 Curtis later proposed this text: 2744 BGP must maintain separate FSM for each configured peer. Each BGP 2745 peer paired in a potential connection will attempt to connect to the 2746 other. For the purpose of this discussions, the active or connect 2747 side of a TCP connection (the side sending the first TCP SYN packet) 2748 is called outgoing. The passive or listening side (the sender of the 2749 first SYN ACK) is called the an incoming connection. 2751 A BGP implementation must connect to and listen on TCP port 179 for 2752 incoming connections in addition to trying to connect to peers. For 2753 each incoming connection, a state machine must be instantiated. 2754 There exists a period in which the identity of the peer on the other 2755 end of an incoming connection is not known with certainty. During 2756 this time, both an incoming and outgoing connection for the same peer 2757 may exist. This is referred to as a connection collision (see 2758 Section x.x, was 6.8). 2760 A BGP implementation will have at most one FSM for each peer plus one 2761 FSM for each incoming TCP connection for which the peer has not yet 2762 been identified. Each FSM corresponds to exactly one TCP connection. 2764 Jonathan pointed out that there was an inaccuracy in the proposed 2765 text. Curtis replied with this: 2767 You're correct in that you must have a collision of IP addresses on 2768 the TCP connections and that the BGP Identifier is used only to 2769 resolve which gets dropped. 2771 The FSM stays around as long as "BGP Identifier" is not known. 2772 Replace "not known with certainty" with "known but the BGP identifier 2773 is not known" and replace "for the same peer" with "for the same 2774 configured peering". 2776 The first paragraph is unchanged: 2778 BGP must maintain separate FSM for each configured peer. Each BGP 2779 peer paired in a potential connection will attempt to connect to the 2780 other. For the purpose of this discussions, the active or connect 2781 side of a TCP connection (the side sending the first TCP SYN packet) 2782 is called outgoing. The passive or listening side (the sender of the 2783 first SYN ACK) is called the an incoming connection. 2785 The second paragraph becomes: 2787 A BGP implementation must connect to and listen on TCP port 179 for 2788 incoming connections in addition to trying to connect to peers. For 2789 each incoming connection, a state machine must be instantiated. 2790 There exists a period in which the identity of the peer on the other 2791 end of an incoming connection is known but the BGP identifier is not 2792 known. During this time, both an incoming and outgoing connection 2793 for the same configured peering may exist. This is referred to as a 2794 connection collision (see Section x.x, was 6.8). 2796 The next paragraph then needs to get fixed. Changed "for each peer" 2797 to "for each configured peering". 2799 A BGP implementation will have at most one FSM for each configured 2800 peering plus one FSM for each incoming TCP connection for which the 2801 peer has not yet been identified. Each FSM corresponds to exactly 2802 one TCP connection. 2804 Add a paragraph to further clarify the point you made. 2806 There may be more than one connection between a pair of peers if the 2807 connections are configured to use a different pair of IP addresses. 2808 This is referred to as multiple "configured peerings" to the same 2809 peer. 2811 > So multiple simultaneous BGP connection are allowed between the 2812 same two > peers, and this behavior is implemented, for example to do 2813 load balancing. 2815 Good point. 2817 I hope the corrections above cover your (entirely valid) objections. 2818 If you see any more errors please let me know. 2820 Tom replied that: 2822 I take issue with the 'will attempt to connect' which goes too far. 2824 The FSM defines events 4 and 5, 'with passive Transport 2825 establishment', so the system may wait and not attempt to connect. 2826 The exit from this state is either the receipt of an incoming TCP 2827 connection (SYN) or timer expiry. 2829 So we may have a FSM attempting to transport connect for a given 2830 source/destination IP pair or we may have an FSM not attempting to 2831 connect. (In the latter case, I do not think we can get a 2832 collision). In the latter case, an incoming connection should not 2833 generate an additional FSM. 2835 I do not believe the concept of active and passive is helpful since a 2836 given system can flip from one to the other and it does not help us 2837 to clarify the number of FSM involved.. 2839 And Curtis suggested that: 2841 Could this be corrected by replacing "will attempt to connect" with 2842 "unless configured to remain in the idle state, or configured to 2843 remain passive, will attempt to connect". We could also shorten that 2844 to "will attempt to connect unless configured otherwise". 2846 Clarification (perhaps an item for a glossary entry): 2848 The terms active and passive have been in our vocabulary for almost a 2849 decade and have proven useful. The words active and passive have 2850 slightly different meanings applied to a TCP connection or applied to 2851 a peer. There is only one active side and one passive side to any 2852 one TCP connection as per the definition below. When a BGP speaker 2853 is configured passive it will never attempt to connect. If a BGP 2854 speaker is configured active it may end up on either the active or 2855 passive side of the connection that eventually gets established. 2856 Once the TCP connection is completed, it doesn't matter which end was 2857 active and which end was passive and the only difference is which 2858 side of the TCP connection has port number 179. 2860 Tom agreed with Curtis, that he liked the "will attempt to connect 2861 unless configured otherwise" verbiage. 2863 This was discussed in the "Generial Editorial Comment" thread. 2865 Sue proposed we add the text above in section 8.2. It is summarized 2866 here for clarity: 2868 8.2) Description of FSM 2870 8.2.1) FSM connections 2872 (text below) 2874 8.2.2) FSM Definition 2876 (text now in 8.2) 2878 "BGP must maintain a separate FSM for each configured peer plus Each 2879 BGP peer paired in a potential connection unless configured to remain 2880 in the idle state, or configured to remain passive, will attempt to 2881 to connect to the other. For the purpose of 2882 this discussion, the active or connect side of the TCP 2883 connection (the side of a TCP connection (the side sending 2884 the first TCP SYN packet) is called outgoing. The passive or 2885 listening side (the sender of the first SYN ACK) is called 2886 an incoming connection. [See section on the terms active and passive 2887 below.] 2889 A BGP implementation must connect to and listen on TCP port 179 for 2890 incoming connections in addition to trying to connect to peers. Fro 2891 each incoming connection, a state machine must be instantiated. 2892 There exists a period in which the identity of the peer on the other 2893 end of an incoming connection is known but the BGP identifier is not 2894 known. During this time, both an incoming and an outgoing connection 2895 for the same configured peering may exist. This is referred to as a 2896 connection collision (see Section x.x, was 6.8). 2898 A BGP implementation will have at most one FSM for each configured 2899 peering plus one FSM for each incoming TCP connection for which the 2900 peer has not yet been identified. Each FSM corresponds to exactly one 2901 TCP connection. 2903 There may be more than one connections between a pair of peers if the 2904 connections are configured to use a different pair of IP addresses. 2905 This is referred to as multiple "configured peerings" to the same 2906 peer. 2908 8.2.1.1) Terms "active" and "passive" 2910 The terms active and passive have been in our vocabulary for almost a 2911 decade and have proven useful. The words active and passive have 2912 slightly different meanings applied to a TCP connection or applied to 2913 a peer. There is only one active side and one passive side to any 2914 one TCP connection per the definition above [and the state machine 2915 below.] When a BGP speaker is configured active it may end up on 2916 either the active or passive side of the connection that eventually 2917 gets established. Once the TCP connection is completed, it doesn't 2918 matter which end was active and which end was passive and the only 2919 difference is which side of the TCP connection has port number 179. 2921 For additional text, see issue 46. 2923 Sue solicited additional comments, the only one was on 2924 capitalization, so it would appear we are at consensus with this 2925 issue. 2927 2.49 Explicitly Define Event Generation 2929 Status: Consensus 2930 Change: No 2931 Summary: Suggested that we explicitly define BGP message processing. 2932 No text proposed. There has been no further discussion on this 2933 issue, it is assumed that the consensus is that things are ok the way 2934 they are. 2936 Discussion: 2938 Alex suggested we explicitly define: 2940 - generation of events while processing BGP messages, i.e., the text 2941 describing message processing should say where needed that a specific 2942 event for the BGP session should be generated. 2944 No text was proposed. 2946 This discussion has received no further comment. Unless someone 2947 wants to reopen it, it is assumed it has reached a happy ending. 2949 This was discussed in the "Generial Editorial Comment" thread. 2951 2.50 FSM Timers 2953 Status: Consensus 2954 Change: No 2955 Summary: Discussion tabled, because new document version rendered the 2956 discussion moot. 2958 Discussion: 2960 This discussion began with a suggestion that the timers currently in 2961 the FSM: 2963 In the 26 Aug text, I find the timer terminology still confusing. 2964 Timers can, I find, stop start restart clear set reset expire 2966 Can be cleaned up and simplified to: 2968 start with initial value (spell it out just to be sure) stop expire 2970 A response to this proposal was, that the existing set is clear, and 2971 that the proposed set is insufficiently rich to describe a concept 2972 like "reset" which encompasses: "Stop the timer, and reset it to its 2973 initial value." 2974 This discussion reached an impasse, when Sue pointed out that the 2975 text had been updated, and to please review the new text. 2977 This was discussed in the "FSM more words" thread. 2979 2.51 FSM ConnectRetryCnt 2981 Status: Consensus 2982 Change: No 2983 Summary: Discussion tabled, because new document version rendered the 2984 discussion moot. 2986 Discussion: 2988 This started with the observation that the ConnectRetryCnt "seems to 2989 have lost its purpose." It was suggested that this be made a Session 2990 Attribute, along with: OpenDelayTimer and DelayOpenFlag. 2992 Curtis explained that the current purpose of the ConnectRetryCnt is 2993 something to be read by the MIB. He also advocated against adding 2994 the additional Session Attributes. 2996 2.52 Section 3: Keeping routes in Adj-RIB-In 2998 Status: Consensus 2999 Change: Yes 3000 Summary: Add: To allow local policy changes to have the correct 3001 effect without resetting any BGP connections, a BGP speaker SHOULD 3002 either (a) retain the current version of the routes advertised to it 3003 by all of its peers for the duration of the connection, or (b) make 3004 use of the Route Refresh extension [12]. 3006 Discussion: 3008 This thread started with a question about why we should retain routes 3009 in the Adj-RIB-In, and how it relates to the Route Refresh extension. 3011 mrr proposed this text: 3013 ... Therefore, a BGP speaker must either retain the current version 3014 of the routes advertised by all of its peers for the duration of the 3015 connection, or make use of the Route Refresh extension [12]. This is 3016 necessary to allow local policy changes to have the correct effect 3017 without requiring the reset of any peering sessions. 3019 If the implementation decides not to retain the current version of 3020 the routes that have been received from a peer, then Route Refresh 3021 messages should be sent whenever there is a change to local policy. 3023 Yakov later suggested this text, with a slight rewording: 3025 To allow local policy changes to have the correct effect without 3026 resetting any BGP connections, a BGP speaker SHOULD either (a) 3027 retain the current version of the routes advertised to it by all of 3028 its peers for the duration of the connection, or (b) make use of the 3029 Route Refresh extension [12]. 3031 mrr responded that he was fine with Yakov's suggestions. 3033 This was discussed in the "Proxy: comments on section 3" thread. 3035 2.53 Section 4.3 - Routes v. Destinations - Advertise 3037 Status: Consensus 3038 Change: No 3039 Summary: The text that has reached consensus in issue 54 also 3040 addresses this issue. 3042 Discussion: 3044 This issue arose out of this question to the list: 3046 Since: 3048 "For the purpose of this protocol, a route is defined as a unit of 3049 information that pairs a set of destinations with the attributes of a 3050 path to those destinations. The set of destinations are the systems 3051 whose IP addresses are reported in the Network Layer Reachability 3052 Information (NLRI) field and the path is the information reported in 3053 the path attributes field of the same UPDATE message." 3055 When I read section 4.3: 3057 "An UPDATE message is used to advertise feasible routes sharing 3058 common path attribute to a peer, or to withdraw multiple unfeasible 3059 routes from service (see 3.1)." 3061 Shouldn't the text read "... advertise feasible [prefixes | 3062 destinations] sharing common path attribute(S)to a peer ...", 3063 because: 3065 1) A route is defined as quoted above from section 3.1? 3067 or since ... 3069 "An UPDATE message can advertise at most one set of path attributes, 3070 but multiple destinations ..." 3071 2) make "routes" in the original singular. 3073 This was discussed in the "Review Comments: Section 4.3: "routes" vs. 3074 destinations - advertise" thread. 3076 The text that has reached consensus in issue 54 also addresses this 3077 issue. 3079 2.54 Section 4.3 - Routes v. Destinations - Withdraw 3081 Status: Consensus 3082 Change: Yes 3083 Summary: Change the definition of "route" as it currently stands to: 3085 For the purpose of this protocol, a route is defined as a unit of 3086 information that pairs a set of destinations with the attributes of a 3087 path to those destinations. The set of destinations are systems whose 3088 IP addresses are contained in one IP address prefix carried in the 3089 Network Layer Reachability Information (NLRI) field of an UPDATE 3090 message and the path is the information reported in the path 3091 attributes field of the same UPDATE message. 3093 Multiple routes that have the same path attributes can be advertised 3094 in a single UPDATE message by including multiple prefixes in the NLRI 3095 field of the UPDATE message. 3097 Discussion: 3099 This issue was brought up with this question: 3101 When I read these two paragraphs at the end of section 4.3: 3103 "An UPDATE message can list multiple routes to be withdrawn from 3104 service. Each such route is identified by its destination (expressed 3105 as an IP prefix), which unambiguously identifies the route in the 3106 context of the BGP speaker - BGP speaker connection to which it has 3107 been previously advertised. 3109 An UPDATE message might advertise only routes to be withdrawn from 3110 service, in which case it will not include path attributes or Network 3111 Layer Reachability Information. Conversely, it may advertise only a 3112 feasible route, in which case the WITHDRAWN ROUTES field need not be 3113 present." 3115 It reads as if one must withdraw the _set of destinations_ advertised 3116 with the route instead of just one or more destinations since route 3117 is defined in section 3.1 as: 3119 "For the purpose of this protocol, a route is defined as a unit of 3120 information that pairs a set of destinations with the attributes of a 3121 path to those destinations. The set of destinations are the systems 3122 whose IP addresses are reported in the Network Layer Reachability 3123 Information (NLRI) field and the path is the information reported in 3124 the path attributes field of the same UPDATE message." 3126 Shouldn't the text change "routes" to destinations, or to prefixes? 3128 The original commenter added this clarification later: 3130 I meant to say, the *same* set of destinations as those advertised 3131 initially. For example, NLRI with dest-a, dest-b and dest-c with the 3132 same attributes is a "route". The withdrawal of the "route" can be 3133 read as one must withdraw all destinations originally advertised for 3134 that route (dest-a, dest-b, dest-c) as a unit. 3136 A first time reader could be left wondering if the above must be the 3137 case, or it is valid for an implementation to withdraw just one of 3138 these destinations (e.g. dest-b), leaving the others (dest-a, dest-c) 3139 reachable with their attributes intact. 3141 If there is no relationship between destinations when advertised as a 3142 set of destinations in a route and those destinations that can be 3143 withdrawn should be explicitly stated. Otherwise, the draft should 3144 call out that it is not legal to withdraw one prefix only in the set 3145 of prefixes advertised as previously as route. 3147 Matt suggested that since the definition seems to cause some 3148 confusion, that we update the definition to: 3150 "For the purpose of this protocol, a route is defined as a unit of 3151 information that pairs a set of destinations with the attributes of a 3152 path to those destinations. The set of destinations are systems 3153 whose IP addresses are reported in one prefix present in the Network 3154 Layer Reachability Information (NLRI) field of an UPDATE and the path 3155 is the information reported in the path attributes field of the same 3156 UPDATE message. 3158 This definition allows multiple routes to be advertised in a single 3159 UPDATE message by including multiple prefixes in the NLRI field of 3160 the UPDATE. All such prefixes must be associated with the same set 3161 of path attributes." 3163 Yakov suggested some minor rewording: 3165 For the purpose of this protocol, a route is defined as a unit of 3166 information that pairs a set of destinations with the attributes of a 3167 path to those destinations. The set of destinations are systems whose 3168 IP addresses are contained in one IP address prefix carried in the 3169 Network Layer Reachability Information (NLRI) field of an UPDATE 3170 message and the path is the information reported in the path 3171 attributes field of the same UPDATE message. 3173 Multiple routes that have the same path attributes can be advertised 3174 in a single UPDATE message by including multiple prefixes in the NLRI 3175 field of the UPDATE message. 3177 Both Jeff and Matt responded that they liked this text. 3179 2.55) Section 4.3 - Description of AS_PATH length 3181 Status: Consensus 3182 Change: Yes 3183 Summary: Replace: 3185 Path segment length is a 1-octet long field containing the number of 3186 ASs in the path segment value field. 3188 With: 3190 Path segment length is a 1-octet long field containing the number of 3191 ASs (not the number of octets) in the path segment value field. 3193 Discussion: 3195 This question was raised: 3197 Length fields elsewhere in the draft specify the number of bytes that 3198 a variable length field uses. For AS_PATH, length is used as the 3199 number of 2 byte AS numbers. In the interest of not having to check 3200 other sources to be sure, should the description of path segment 3201 value: 3203 "The path segment value field contains one or more AS numbers, each 3204 encoded as a 2-octets long field." 3206 explicitly mention the number of bytes used by the variable length 3207 field? 3209 Or, make the description of length explicitly mention that it is not 3210 the length of the variable length field as is the case with other 3211 length fields? 3213 One response to this agreed that some more clarification would be 3214 good, specifically an ASCII art diagram. No diagram was proposed. 3216 Yakov proposed this change: 3218 How about replacing 3220 Path segment length is a 1-octet long field containing the number of 3221 ASs in the path segment value field. 3223 with the following 3225 Path segment length is a 1-octet long field containing the number of 3226 ASs (but not the number of octets) in the path segment value field. 3228 Jonathan offered this text: 3230 How about: "Path segment length is a 1-octet long field containing 3231 the number of ASs (which is half the number of octets since each AS 3232 is 2 octets) in the path segment value field (also note that the path 3233 may contain more than 1 segment). 3235 Jeff replied that he preferred Yakov's text, but without the "but". 3236 Yakov agreed to that. Andrew also agreed, and asked if there were 3237 any objections to moving this issue into consensus. There were no 3238 objections. 3240 2.56 Section 6 - BGP Error Handling 3242 Status: Consensus 3243 Change: Yes 3244 Summary: There are a variety of updates to the text that are best 3245 described in the discussion section. 3247 Discussion: 3249 This discussion began with some suggestions on ways to clarify the 3250 text in section 6 dealing with error handling. The original 3251 comments, and Yakov's response are below: 3253 > At the beginning of Section 6. BGP Error Handling: 3254 > 3255 > 3256 > "When any of the conditions described here are detected, a 3257 > NOTIFICATION message with the indicated Error Code, Error 3258 Subcode, 3259 > and Data fields is sent, and the BGP connection is closed." 3260 > 3261 > There are several cases where the conditions described in this 3262 section 3263 > do not result in the BGP connection being closed. These conditions 3264 > should either state that the connection stays up. Another 3265 possibility 3266 > is to remove "and the BGP connection is closed." above, and for 3267 each 3268 > listed connection, state what happens to the BGP connection. This 3269 > already takes place for certain conditions, but isn't done 3270 consistently. 3272 How about replacing the above with the following: 3274 When any of the conditions described here are detected, a 3275 NOTIFICATION message with the indicated Error Code, Error Subcode, 3276 and Data fields is sent, and the BGP connection is closed, unless it 3277 is explicitly stated that no NOTIFICATION message is to be sent and 3278 the BGP connection is not to be close. 3280 > I tried to list what I found (which may be wrong or incomplete) 3281 below: 3282 > 3283 > 3284 > "If the NEXT_HOP attribute is semantically incorrect, the error 3285 should 3286 > be logged, and the route should be ignored. In this case, no 3287 > NOTIFICATION message should be sent." 3288 > 3289 > * Append the connection is not closed. 3291 Done. 3293 > 3294 > "(a) discard new address prefixes from the neighbor, or (b) 3295 terminate 3296 > the BGP peering with the neighbor." 3297 > 3298 > * Append "the connection is not closed" to case (a) 3300 added "(while maintaining BGP peering with the neighbor)" to case 3301 (a). 3303 > 3304 > "If the autonomous system number appears in the AS path the 3305 > route may be stored in the Adj-RIB-In," 3306 > 3307 > * append and the BGP connection stays up. 3308 > 3309 > "but unless the router is configured to accept routes with its 3310 > own autonomous system in the AS path, the route shall not be 3311 > passed to the BGP Decision Process." 3312 I would suggest to move this text to Section 9 (UPDATE message 3313 handling), as receiving a route with your own AS in the AS path isn't 3314 really an error. It is just that usually (but not always) you can't 3315 put this route in your Adj-RIB-In. 3317 > * Q1) does the BGP connection stay up? 3319 yes. 3321 > * Q2) what if the router isn't configured to accept routes with its 3322 > own AS in the AS path? One _may_ store the route in Adj-RIB-In, 3323 but 3324 > if one doesn't want to? 3326 So, don't store them. 3328 > Is the BGP connection closed? If so, what subcode? 3330 The connection is *not* closed. 3332 > "If an optional attribute is recognized, then the value of this 3333 > attribute is checked. If an error is detected, the attribute is 3334 > discarded, and the Error Subcode is set to Optional Attribute 3335 Error. 3336 > The Data field contains the attribute (type, length and 3337 value)." 3338 > 3339 > * Append and the BGP connection stays up after "the attribute is 3340 discarded". 3342 Since you have to close the connection, you have to discard all the 3343 routes received via this connection, including the route with the 3344 incorrect attribute. So, there is no need to say that "the attribute 3345 is discarded". 3347 There have been no objections to the updates listed above. This 3348 issue seems to have reached a happy ending, so it has been moved into 3349 consensus. 3351 This was discussed in the "-17 review Section 6 - BGP Error 3352 Handling." thread. 3354 2.57 Section 6.2 - Hold timer as Zero 3356 Status: Consensus 3357 Change: No 3358 Summary: It was suggested that we update the text to say that we MUST 3359 reject hold time values of zero. It was pointed out that this is not 3360 the case and the text should say the way it is. 3362 Discussion: 3364 In Section 6.2 on OPEN message error handling: 3366 If the Hold Time field of the OPEN message is unacceptable, then the 3367 Error Subcode MUST be set to Unacceptable Hold Time. An 3368 implementation MUST reject Hold Time values of one or two seconds. 3370 I feel that text similar to: 3372 "An implementation MUST also reject Hold Time values of zero received 3373 from a peer in a different AS" should be considered for completeness. 3375 A number of respondents pointed out that zero hold time is legitimate 3376 under certain circumstances. 3378 This was discussed in the "-17 review, Section 6.2 - must reject hold 3379 time" thread. 3381 2.58 Deprecation of ATOMIC_AGGREGATE 3383 Status: Consensus 3384 Change: Yes 3385 Summary: For new text, please see the end of the discussion. 3387 Discussion: 3389 Jeff opened this discussion with: 3391 Deprecation of ATOMIC_AGGREGATE: 3393 [This is a summary of some discussions from those who have "been 3394 there, done that" during the CIDR deployment period and also comments 3395 from network operators on the NANOG list.] 3397 When BGP-4 was originally drafted, the topic of aggregation was new 3398 enough that people didn't exactly know how it would be used. 3399 Additionally, there were some transition issues when aggregated 3400 networks would need to be de-aggregated and re-advertised into a 3401 classful routing mesh such as BGP-3. 3403 The ATOMIC_AGGREGATE flag was intended to prevent a route from being 3404 de-aggregated when de-aggregation would introduce routing loops. 3405 Note that de-aggregation in this context specifically means making a 3406 less specific route into one or more more-specific routes. 3408 The current BGP draft has two situations where ATOMIC_AGGREGATE 3409 should be appended to a route: 1. When a route's AS_PATH is 3410 intentionally truncated, such as what happens by default on Cisco's, 3411 or using the "brief" option on GateD. Juniper has a similar feature 3412 - I'm unsure of the default. 2. When two routes are implicitly 3413 aggregated in the LocRib such that a more specific route is not 3414 selected when a less specific route is from a given peer. 3416 Note that this particular feature is not implemented anywhere that I 3417 am aware of. 3419 3. There is a third case not covered by the specification: Implicit 3420 aggregation on export - a more specific route is not exported and 3421 only a less specific one is. 3423 When network operators were asked about de-aggregation practices, I 3424 received about 40 responses. The majority of these responses 3425 confused de-aggregation with leaking existing more-specific routes 3426 that are used internally rather than explicitly de-aggregating a 3427 less-specific route. 3429 There were a very few cases of explicit de-aggregation. One form was 3430 done for purposes of dealing with another ISP creating a routing DoS 3431 by advertising IP space that didn't belong to them - leaked more 3432 specifics alleviated the problem in many cases. (Note that this is a 3433 security issue in the routing system.) 3435 The second case was de-aggregating routes internally (and sending the 3436 routes via IBGP marked with NO-ADVERTISE) for purposes of traffic 3437 engineering routing internally where a given upstream failed to 3438 provide enough routing information to allow traffic flows to be 3439 optimized based on supplied prefixes. 3441 My conclusions to this are: 1. De-aggregation is not a common 3442 practice. 2. It is no longer a major concern since classful inter- 3443 domain routing is pretty much gone. 3. The spec doesn't match 3444 reality and should be corrected. 3446 My suggestions are thus this: Section 5.1.6 should be updated as 3447 follows: ATOMIC_AGGREGATE is a well-known discretionary attribute. 3448 Its use is deprecated. 3450 When a router explicitly aggregates several routes for the purpose of 3451 advertisement to a particular peer, and the AS_PATH of the aggregated 3452 route excludes at least some of the AS numbers present in the AS_PATH 3453 of the routes that are aggregated (usually due to truncation), the 3454 aggregated route, when advertised to the peer, MUST include the 3455 ATOMIC_AGGREGATE attribute. 3457 Section 9.1.4 should be updated as follows: 3458 Original text: 3459 If a BGP speaker receives overlapping routes, the Decision 3460 Process 3461 MUST consider both routes based on the configured acceptance 3462 policy. 3463 If both a less and a more specific route are accepted, then the 3464 Decision Process MUST either install both the less and the more 3465 specific routes or it MUST aggregate the two routes and install 3466 the 3467 aggregated route, provided that both routes have the same value 3468 of 3469 the NEXT_HOP attribute. 3471 If a BGP speaker chooses to aggregate, then it MUST add 3472 ATOMIC_AGGREGATE attribute to the route. A route that carries 3473 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3474 NLRI of this route can not be made more specific. Forwarding 3475 along 3476 such a route does not guarantee that IP packets will actually 3477 traverse only ASs listed in the AS_PATH attribute of the route. 3479 Replace with: 3481 It is common practice that more specific routes are often implicitly 3482 aggregated by selecting or advertising only a less-specific route 3483 when overlapping routes are present. As such, all routes SHOULD be 3484 treated as if ATOMIC_AGGREGATE is present and not be made more 3485 specific (de-aggregated). De-aggregation may lead to routing loops. 3487 Section 9.2.2 should remain as it is. 3489 Implications of not making the above updates: 3490 ATOMIC_AGGREGATE is not implemented as documented. Current 3491 operational practices do not seem to often trigger situations that it 3492 was intended to re-mediate. After all, by the way it is currently 3493 documented, many of the routes in the Internet would likely have 3494 ATOMIC_AGGREGATE. 3496 The original motivation for this investigation (aside from a few 3497 years of wondering what this portion of the spec *really* meant) was 3498 making sure the MIB is correctly documented. I can do this now, even 3499 if the spec is not corrected by simply noting that the values: 3500 lessSpecificRouteNotSelected(1), 3501 lessSpecificRouteSelected(2) 3503 mean: 3504 ATOMIC_AGGREGATE not present 3505 ATOMIC_AGGREGATE present 3507 rather than documenting anything about less and more specific routes. 3509 The v2MIB can be fixed to just call it what it is since it hasn't 3510 been RFC'ed yet. 3512 Lastly, the spec would just be incorrect. But all said, nothing bad 3513 would really come of this. 3515 Yakov responded to this, saying that he thought these changes were 3516 reasonable, and unless there were objections, they would be adopted. 3518 Ishi strongly agreed with the changes. 3520 Curtis stated that: 3522 We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated 3523 rather than replaced with an AS_SET. It was always purely 3524 informational since no one intentionally deaggregated and 3525 reannounced. 3527 And suggested that we remove the MUSTs and indicated that this is 3528 only informational. 3530 Jeff replied that: 3532 The point is that by definition of the attribute, anywhere that 3533 policy is used (and some places where it may not be), 3534 ATOMIC_AGGREGATE *should* be there. Since its not, and it would 3535 generally be everywhere, you just shouldn't de-aggregate. 3537 At best, leaving it as a method of informationally signalling 3538 truncation of a AS_PATH is the best we'll get out of it - and it 3539 matches current implementations. 3541 Jonathan agreed with Curtis' idea that we should just move 3542 ATOMIC_AGGREGATE to informational. 3544 Curtis proposed this text: 3546 This existing text is fine: 3548 f) ATOMIC_AGGREGATE (Type Code 6) 3550 ATOMIC_AGGREGATE is a well-known discretionary attribute of 3551 length 0. Usage of this attribute is described in 5.1.6. 3553 This is the existing text that we are considering changing: 3555 5.1.6 ATOMIC_AGGREGATE 3557 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3559 When a router aggregates several routes for the purpose of 3560 advertisement to a particular peer, and the AS_PATH of the aggregated 3561 route excludes at least some of the AS numbers present in the AS_PATH 3562 of the routes that are aggregated, the aggregated route, when 3563 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3565 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3566 attribute MUST NOT remove the attribute from the route when 3567 propagating it to other speakers. 3569 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3570 attribute MUST NOT make any NLRI of that route more specific (as 3571 defined in 9.1.4) when advertising this route to other BGP speakers. 3573 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3574 attribute needs to be cognizant of the fact that the actual path to 3575 destinations, as specified in the NLRI of the route, while having the 3576 loop-free property, may not be the path specified in the AS_PATH 3577 attribute of the route. 3579 Suggested new text: 3581 5.1.6 ATOMIC_AGGREGATE 3583 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3585 When a router aggregates several routes for the purpose of 3586 advertisement to a particular peer, the AS_PATH of the aggregated 3587 route normally includes an AS_SET formed from the set of AS from 3588 which the aggregate was formed. In many cases the network 3589 administrator can determine that the aggregate can safely be 3590 advertised without the AS_SET and not form route loops. 3592 If an aggregate excludes at least some of the AS numbers present in 3593 the AS_PATH of the routes that are aggregated as a result of dropping 3594 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3595 include the ATOMIC_AGGREGATE attribute. 3597 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3598 attribute SHOULD NOT remove the attribute from the route when 3599 propagating it to other speakers. 3601 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3602 attribute MUST NOT make any NLRI of that route more specific (as 3603 defined in 9.1.4) when advertising this route to other BGP speakers. 3605 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3606 attribute needs to be cognizant of the fact that the actual path to 3607 destinations, as specified in the NLRI of the route, while having the 3608 loop-free property, may not be the path specified in the AS_PATH 3609 attribute of the route. 3611 Diffs (for reader convenience): 3613 @@ -4,13 +4,19 @@ ATOMIC_AGGREGATE is a well-known discretionary 3614 attribute. 3616 When a router aggregates several routes for the purpose of 3617 - advertisement to a particular peer, and the AS_PATH of the 3618 - aggregated route excludes at least some of the AS numbers 3619 - present in the AS_PATH of the routes that are aggregated, 3620 - the aggregated route, when advertised to the peer, MUST 3621 - include the ATOMIC_AGGREGATE attribute. 3622 + advertisement to a particular peer, the AS_PATH of the 3623 + aggregated route normally includes an AS_SET formed from the 3624 + set of AS from which the aggregate was formed. In many cases 3625 + the network administrator can determine that the aggregate can 3626 + safely be advertised without the AS_SET and not form route loops. 3627 + 3628 + If an aggregate excludes at least some of the AS numbers present 3629 + in the AS_PATH of the routes that are aggregated as a result of 3630 + dropping the AS_SET, the aggregated route, when advertised to the 3631 + peer, SHOULD include the ATOMIC_AGGREGATE attribute. 3633 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3634 - attribute MUST NOT remove the attribute from the route when 3635 + attribute SHOULD NOT remove the attribute from the route when 3636 + propagating it to other speakers. 3638 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3640 Current text in 9.1.4: 3642 If a BGP speaker chooses to aggregate, then it MUST add 3643 ATOMIC_AGGREGATE attribute to the route. A route that carries 3644 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3645 NLRI of this route can not be made more specific. Forwarding along 3646 such a route does not guarantee that IP packets will actually 3647 traverse only ASs listed in the AS_PATH attribute of the route. 3649 Change to: 3651 If a BGP speaker chooses to aggregate, then it SHOULD either include 3652 all AS used to form the aggregate in an AS_SET or add the 3653 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3654 primarily informational. With the elimination of IP routing 3655 protocols that do not support classless routing and the elimination 3656 of router and host implementations that do not support classless 3657 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3658 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3659 particular MUST NOT be de-aggregated. That is, the NLRI of this route 3660 can not be made more specific. Forwarding along such a route does not 3661 guarantee that IP packets will actually traverse only ASs listed in 3662 the AS_PATH attribute of the route. 3664 This text in 9.2.2.2 need not change. 3666 ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has 3667 ATOMIC_AGGREGATE path attribute, then the aggregated route shall have 3668 this attribute as well. 3670 The appendix need not change: 3672 Appendix 1. Comparison with RFC1771 3674 [...] 3676 Clarifications to the use of the ATOMIC_AGGREGATE attribute. 3678 This might be a bit more wordy that is necessary. It does address 3679 the objections to keeping ATOMIC_AGGREGATE by making the MUST into 3680 SHOULD, and explaining that ATOMIC_AGGREGATE is now primarily 3681 informational. 3683 Yakov was fine with this text. 3685 Yakov posted the text that represents the WG consensus: 3687 Replace: 3689 5.1.6 ATOMIC_AGGREGATE 3691 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3693 When a router aggregates several routes for the purpose of 3694 advertisement to a particular peer, and the AS_PATH of the aggregated 3695 route excludes at least some of the AS numbers present in the AS_PATH 3696 of the routes that are aggregated, the aggregated route, when 3697 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3699 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3700 attribute MUST NOT remove the attribute from the route when 3701 propagating it to other speakers. 3703 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3704 attribute MUST NOT make any NLRI of that route more specific (as 3705 defined in 9.1.4) when advertising this route to other BGP speakers. 3707 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3708 attribute needs to be cognizant of the fact that the actual path to 3709 destinations, as specified in the NLRI of the route, while having the 3710 loop-free property, may not be the path specified in the AS_PATH 3711 attribute of the route. 3713 with: 3715 5.1.6 ATOMIC_AGGREGATE 3717 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3719 When a router aggregates several routes for the purpose of 3720 advertisement to a particular peer, the AS_PATH of the aggregated 3721 route normally includes an AS_SET formed from the set of AS from 3722 which the aggregate was formed. In many cases the network 3723 administrator can determine that the aggregate can safely be 3724 advertised without the AS_SET and not form route loops. 3726 If an aggregate excludes at least some of the AS numbers present in 3727 the AS_PATH of the routes that are aggregated as a result of dropping 3728 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3729 include the ATOMIC_AGGREGATE attribute. 3731 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3732 attribute SHOULD NOT remove the attribute from the route when 3733 propagating it to other speakers. 3735 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3736 attribute MUST NOT make any NLRI of that route more specific (as 3737 defined in 9.1.4) when advertising this route to other BGP speakers. 3739 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3740 attribute needs to be cognizant of the fact that the actual path to 3741 destinations, as specified in the NLRI of the route, while having the 3742 loop-free property, may not be the path specified in the AS_PATH 3743 attribute of the route. 3745 In 9.1.4 replace: 3747 If a BGP speaker chooses to aggregate, then it MUST add 3748 ATOMIC_AGGREGATE attribute to the route. A route that carries 3749 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3750 NLRI of this route can not be made more specific. Forwarding along 3751 such a route does not guarantee that IP packets will actually 3752 traverse only ASs listed in the AS_PATH attribute of the route. 3754 with: 3756 If a BGP speaker chooses to aggregate, then it SHOULD either include 3757 all AS used to form the aggregate in an AS_SET or add the 3758 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3759 primarily informational. With the elimination of IP routing 3760 protocols that do not support classless routing and the elimination 3761 of router and host implementations that do not support classless 3762 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3763 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3764 particular MUST NOT be de-aggregated. That is, the NLRI of this route 3765 can not be made more specific. Forwarding along such a route does not 3766 guarantee that IP packets will actually traverse only ASs listed in 3767 the AS_PATH attribute of the route. 3769 This met with agreement. This issue is at consensus. 3771 2.59 Section 4.3 - Move text 3773 Status: Consensus 3774 Change: Yes (minimal) 3775 Summary: Update indentation to allow a new "subsection" heading. 3776 Otherwise no change. 3778 Discussion: 3780 This began with this suggestion: 3782 The text about the minimum length, at first look, gives the 3783 impression that it is still part of the NLRI field description and/or 3784 the Path Attributes section. A new "subsection" or heading of some 3785 sort would be helpful in switching context back to the UPDATE message 3786 as a whole and not the path attributes field anymore. 3788 Yakov agreed to update the indentation. 3790 Jonathan agreed, and suggested this text: 3792 " The minimum length of the UPDATE message is 23 octets -- 19 octets 3793 for the fixed header + 2 octets for the Withdrawn Routes Length + 2 3794 octets for the Total Path Attribute Length (the value of Withdrawn 3795 Routes Length is 0 and the value of Total Path Attribute Length is 3796 0)." 3798 Should be moved up to just after 3800 "... the Total Path Attribute Length field and the 3801 Withdrawn Routes Length field." 3803 Yakov responded to this with: 3805 Disagree, as "... the Total Path Attribute Length field and the 3806 Withdrawn Routes Length field." explains how to calculate the length 3807 of NLRI field (and therefore is part of the NLRI field description), 3808 while "The minimum length of the UPDATE message is 23 octets...." 3809 has to do with the length of the UPDATE message. 3811 Jonathan also suggested: 3813 " the value of Withdrawn Routes Length is 0 and the value of Total 3814 Path Attribute Length is 0)." 3816 Should be changed to 3818 " the min. value of Withdrawn Routes Length is 0 and the min. value 3819 of Total Path Attribute Length is 0)." 3821 And Yakov responded with: 3823 Disagree, as the text doesn't talk about what is the minimum value of 3824 the Withdrawn Routes Length and Total Path Attribute Length fields, 3825 but talks about the value of these fields in the case of a min length 3826 UPDATE message. 3828 After Yakov's response and a posting to the list asking that this be 3829 moved to consensus, there were no objections, so this is moved to 3830 consensus. 3832 This is discussed in the "Review: Comments: Section 4.3: UPDATE min 3833 length" thread. 3835 2.60 Section 4.3 - Path Attributes 3837 Status: Consensus 3838 Change: Yes 3839 Summary: Make this change to clarify path attributes in an UPDATE: 3841 To correct the confusion I propose to replace: 3843 A variable length sequence of path attributes is present in every 3844 UPDATE. 3846 with: 3848 A variable length sequence of path attributes is present in every 3849 UPDATE message, except for an UPDATE message that carries only the 3850 withdrawn routes. 3852 Discussion: 3854 This thread began with MikeC pointing out: 3856 The top of page 13 says: 3858 "A variable length sequence of path attributes is present in every 3859 UPDATE." 3861 Is this really true, given that later, in the second to last 3862 paragraph of this section (4.3): 3864 "An UPDATE message might advertise only routes to be withdrawn from 3865 service, in which case it will not include path attributes or Network 3866 Layer Reachability Information." 3868 This could be confusing to a first time reader. 3870 The path attribute length is present in every UPDATE, the path 3871 attribute field itself can be left out, both according to the 3872 description of the minimum length of the UPDATE message and 3873 (implied?) in the picture of the UPDATE message at the beginning of 3874 section 4.3. 3876 This met with one agreement. 3878 Yakov then proposed that: 3880 To correct the confusion I propose to replace: 3882 A variable length sequence of path attributes is present in every 3883 UPDATE. 3885 with: 3887 A variable length sequence of path attributes is present in every 3888 UPDATE message, except for an UPDATE message that carries only the 3889 withdrawn routes. 3891 There was one agreement with this proposal. 3893 This is discussed in the thread: "Review: Section 4.3 - Path 3894 Attributes" 3896 2.61 Next Hop for Redistributed Routes 3898 Status: Consensus 3899 Change: Yes 3900 Summary: More clearly specify the behavior of NEXT_HOP modification, 3901 for the text see the end of the discussion. 3903 Discussion: 3905 Jonathan began this thread with: 3907 I propose adding: 3909 "When announcing a locally originated route to an internal peer, the 3910 BGP speaker should use as the NEXT_HOP the interface address of the 3911 router through which the announced network is reachable for the 3912 speaker; if the route is directly connected to the speaker, or the 3913 interface address of the router through which the announced network 3914 is reachable for the speaker is the internal peer's address, then the 3915 BGP speaker should use for the NEXT_HOP attribute its own IP address 3916 (the address of the interface that is used to reach the peer)." 3918 AFTER 3920 "When sending a message to an internal peer, the BGP speaker should 3921 not modify the NEXT_HOP attribute, unless it has been explicitly 3922 configured to announce its own IP address as the NEXT_HOP." 3924 There has been no discussion on this. 3926 This is discussed in the "Next hop for redistributed routes" thread. 3928 Issue 14 closed in favor of this issue. 3930 In response to Yakov's call for input, Michael responded that: 3932 Section 5.1.3 explicitly states what to do when originating to an 3933 external peer. #2 covers one hop away, #3 covers more than on hop 3934 away. #1 talks about sending to an iBGP peer, but only when 3935 propagating a route received from an eBGP peer. 3937 1) When sending a message to an internal peer, the BGP speaker should 3938 not modify the NEXT_HOP attribute, unless it has been explicitly 3939 configured to announce its own IP address as the NEXT_HOP. 3941 Text similar to #2 should be added, in their own bullet items to #1 3942 such as what was suggested by Jonathan Natale (text is above.) 3944 Yakov replied with this: 3946 Replace: 3948 1) When sending a message to an internal peer, the BGP speaker should 3949 not modify the NEXT_HOP attribute, unless it has been explicitly 3950 configured to announce its own IP address as the NEXT_HOP. 3952 with: 3954 1) When sending a message to an internal peer, if the route is not 3955 locally originated the BGP speaker should not modify the NEXT_HOP 3956 attribute, unless it has been explicitly configured to announce its 3957 own IP address as the NEXT_HOP. When announcing a locally originated 3958 route to an internal peer, the BGP speaker should use as the NEXT_HOP 3959 the interface address of the router through which the announced 3960 network is reachable for the speaker; if the route is directly 3961 connected to the speaker, or the interface address of the router 3962 through which the announced network is reachable for the speaker is 3963 the internal peer's address, then the BGP speaker should use for the 3964 NEXT_HOP attribute its own IP address (the address of the interface 3965 that is used to reach the peer). 3967 And stated the change would be made if there were no objections. 3968 There have been no objections, so this is at consensus. 3970 2.62 Deprecate BGP Authentication Optional Parameter from RFC1771 3972 Status: Consensus 3973 Change: Yes 3974 Summary: We are at consensus, in that we agree that we should 3975 deprecate the BGP Authentication Optional Parameter as described in 3976 RFC1771 in favor of the mechanism described in RFC2385. The textual 3977 changes are listed at the end of the discussion section of this 3978 issue. 3980 Discussion: 3982 This discussion started in issue 21: Authentication Text Update. 3984 This topic has come up before (July time frame), but was recently 3985 refreshed in the context of issue 21. It began with some questions 3986 to the list as to who used what sort of authentication mechanisms. 3987 From the responses it was clear that MD5 (RFC2385) was the preferred 3988 method. 3990 Eric Gray's message helps to flesh this out: 3992 The question is not whether MD5 authentication is used, it is how is 3993 it implemented in real BGP implementations or - more importantly - 3994 where is the authentication information located in the packets sent 3995 between two BGP peers? This is not strictly an implementation issue 3996 because authentication information is located in different places 3997 depending on which version of MD5 authentication is in use. 3999 As is generally known, options are not necessarily good. Currently, 4000 between RFC 1771 and RFC 2385, there are two very distinct ways to 4001 accomplish a semantically identical function. If the mechanism 4002 defined in RFC 1771 is not supported by a number of interoperable 4003 implementations, it must be deprecated per RFC 2026 prior to 4004 advancing the specification to Draft Standard. If it is not 4005 implemented and actually in use, it should be deprecated if for no 4006 other reason than to make the 4008 To this Yakov responded: 4010 To be more precise, 4012 In cases in which one or more options or features have not been 4013 demonstrated in at least two interoperable implementations, the 4014 specification may advance to the Draft Standard level only if those 4015 options or features are removed. 4017 So, the relevant question is whether we have at least two 4018 implementations that support authentication as described in rfc1771. 4020 Folks who implemented authentication, as described in rfc1771, please 4021 speak up. 4023 There have been no responses to Yakov's question. 4025 There seems to be a consensus that, since it is little used, and 4026 since there are better mechanisms, namely MD5 authentication, we 4027 should deprecate the BGP Authentication Optional Parameter from 4028 RFC1771. 4030 Ok, after some discussion, this is a list of the text that we are 4031 adding, changing or removing: 4033 1) Remove the reference to the authentication optional parameter: 4035 I would suggest to remove the following text from the draft: 4037 This document defines the following Optional Parameters: 4039 a) Authentication Information (Parameter Type 1): 4041 This optional parameter may be used to authenticate a BGP 4042 peer. The Parameter Value field contains a 1-octet 4043 Authentication Code followed by a variable length 4044 Authentication Data. 4046 0 1 2 3 4 5 6 7 8 4047 +-+-+-+-+-+-+-+-+ 4048 | Auth. Code | 4049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4050 | | 4051 | Authentication Data | 4052 | | 4053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4055 Authentication Code: 4057 This 1-octet unsigned integer indicates the 4058 authentication mechanism being used. Whenever an 4059 authentication mechanism is specified for use within 4060 BGP, three things must be included in the 4061 specification: 4063 - the value of the Authentication Code which indicates 4064 use of the mechanism, 4065 - the form and meaning of the Authentication Data, and 4066 - the algorithm for computing values of Marker fields. 4068 Note that a separate authentication mechanism may be 4069 used in establishing the transport level connection. 4071 Authentication Data: 4073 Authentication Data is a variable length field that is 4074 interpreted according to the value of the 4075 Authentication Code field. 4077 2) Update the introduction: 4079 In section 2 (Introduction), sixth paragraph 4081 From: 4083 BGP runs over a reliable transport protocol. This eliminates the need 4084 to implement explicit update fragmentation, retransmission, 4085 acknowledgment, and sequencing. Any authentication scheme used by the 4086 transport protocol (e.g., RFC2385 [10]) may be used in addition to 4087 BGP's own authentication mechanisms. The error notification mechanism 4088 used in BGP assumes that the transport protocol supports a "graceful" 4089 close, i.e., that all outstanding data will be delivered before the 4090 connection is closed. 4092 To: 4094 BGP uses TCP [RFC793] as its transport protocol. This eliminates the 4095 need to implement explicit update fragmentation, retransmission, 4096 acknowledgment, and sequencing. BGP listens on TCP port 179. Any 4097 authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be 4098 used. The error notification mechanism used in BGP assumes that TCP 4099 supports a "graceful" close, i.e., that all outstanding data will be 4100 delivered before the connection is closed. 4102 3) Update the message header format section: 4104 From: 4106 Marker: 4108 This 16-octet field contains a value that the receiver of the 4109 message can predict. If the Type of the message is OPEN, or if 4110 the OPEN message carries no Authentication Information (as an 4111 Optional Parameter), then the Marker must be all ones. 4112 Otherwise, the value of the marker can be predicted by some a 4113 computation specified as part of the authentication mechanism 4114 (which is specified as part of the Authentication Information) 4115 used. The Marker can be used to detect loss of synchronization 4116 between a pair of BGP peers, and to authenticate incoming BGP 4117 messages. 4119 To: 4121 Marker: 4123 This 16-octet field is included for compatibility; it must be 4124 set to all ones. 4126 4) Update the Message Header error handling section: 4128 In section 6.1 (Message Header error handling), second paragraph 4130 From: 4132 The expected value of the Marker field of the message header is all 4133 ones if the message type is OPEN. The expected value of the Marker 4134 field for all other types of BGP messages determined based on the 4135 presence of the Authentication Information Optional Parameter in the 4136 BGP OPEN message and the actual authentication mechanism (if the 4137 Authentication Information in the BGP OPEN message is present). If 4138 the Marker field of the message header is not the expected one, then 4139 a synchronization error has occurred and the Error Subcode is set to 4140 Connection Not Synchronized. 4142 To: 4144 The expected value of the Marker field of the message header is all 4145 ones. If the Marker field of the message header is not as expected, 4146 then a synchronization error has occurred and the Error Subcode is 4147 set to Connection Not Synchronized. 4149 5) Remove a paragraph from the OPEN message error handling section 4150 (section 6.2): 4152 If the OPEN message carries Authentication Information (as an 4153 Optional Parameter), then the corresponding authentication procedure 4154 is invoked. If the authentication procedure (based on Authentication 4155 Code and Authentication Data) fails, then the Error Subcode is set to 4156 Authentication Failure. 4158 6) Update the "Differences from RFC1771 Appendix" 4160 Text not listed here 4162 7) Fix the hole in the numbering by updating: 4164 From: 4166 This document defines the following Optional Parameters: 4168 a) Authentication Information (Parameter Type 1): 4170 To: 4172 This document defines the following Optional Parameters: 4174 a) Optional parameter type 1, Authentication Information, has been 4175 deprecated. 4177 We are at consensus with these changes. 4179 2.63 Clarify MED Removal Text 4181 Status: Consensus 4182 Change: Yes 4183 Summary: Modify text to clear up MED removal behavior. Text is at 4184 the end of the discussion. 4186 Discussion: 4188 This discussion began when Jonathan posted a question to the list: 4190 In reference to: 4192 "A BGP speaker MUST IMPLEMENT a mechanism based on local 4193 configuration which allows the MULTI_EXIT_DISC attribute to be 4194 removed from a route" 4196 Does anybody know how this can be done in IOS??? Looks like it 4197 cannot. 4199 Juniper??? 4201 Other code??? 4203 Change to "SHOULD"??? 4205 Enke responded that: 4207 As the MED value is treated as zero when the MED attribute is 4208 missing, removing the MED attribute is really equivalent to setting 4209 the value to zero. Based on this logic, one can argue that "MED 4210 removal" is supported by multiple vendors. 4212 However, I do see that the current text can be consolidated and 4213 cleaned up: 4215 ------------------------ 4216 5.1.4 MULTI_EXIT_DISC 4218 ... 4220 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4221 which allows the MULTI_EXIT_DISC attribute to be removed from a 4222 route. This MAY be done prior to determining the degree of preference 4223 of the route and performing route selection (decision process phases 4224 1 and 2). 4226 An implementation MAY also (based on local configuration) alter the 4227 value of the MULTI_EXIT_DISC attribute received over an external 4228 link. If it does so, it shall do so prior to determining the degree 4229 of preference of the route and performing route selection (decision 4230 process phases 1 and 2). 4232 ------------------------- 4234 How about this: 4236 A BGP speaker MUST implement a mechanism based on local configuration 4237 which allows the value of MULTI_EXIT_DISC attribute of a received 4238 route to be altered. This shall be done prior to determining the 4239 degree of preference of the route and performing route selection 4240 (decision process phases 1 and 2). 4242 -------------------------- 4244 In responding to a question, Enke also added: 4246 > Humm. I thought with a missing MED it was preferable to be treated 4247 > as worst not as 0. 4249 It was changed a long time ago. Please see the following text in 4250 Sect. 9.1.2.2 of the draft: 4252 In the pseudo-code above, MED(n) is a function which returns the 4253 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4254 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4255 MULTI_EXIT_DISC value, i.e. 0. 4257 Curtis replied to Enke: 4259 If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a 4260 knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should 4261 change the spec to say that MED(n) returns the largest value possible 4262 is MULTI_EXIT_DISC is missing since this has better loop suppression 4263 behavior if the placement of MULTI_EXIT_DISC removal is moved in its 4264 position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out. In 4265 other words, no matter where the removal takes place, we are loop 4266 free without special rules about comparing EBGP before MED removal 4267 and then IBGP after MED removal. The only argument for MED(n) going 4268 to zero for missing MULTI_EXIT_DISC was that Cisco routers did that 4269 (and change would pose an operational issue if there wasn't a knob to 4270 facilitate the change). 4272 Note that when explicitly jamming a MULTI_EXIT_DISC value, such as 4273 zero, the issue of where in the decision process the MULTI_EXIT_DISC 4274 learned from the EBGP peers could still be used becomes a concern 4275 again. Unfortunately these implementation hints are necessary to 4276 remain loop free and so its hard to declare them out of scope, unless 4277 we forbid changing MULTI_EXIT_DISC and just allow it to be removed 4278 (which does not reflect current practice). 4280 Curtis also added: 4282 The other issue was MED handling. In "5.1.4 MULTI_EXIT_DISC": 4284 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4285 which allows the MULTI_EXIT_DISC attribute to be removed from a 4286 route. This MAY be done prior to determining the degree of preference 4287 of the route and performing route selection (decision process phases 4288 1 and 2). 4290 An implementation MAY also (based on local configuration) alter the 4291 value of the MULTI_EXIT_DISC attribute received over an external 4292 link. If it does so, it shall do so prior to determining the degree 4293 of preference of the route and performing route selection (decision 4294 process phases 1 and 2). 4296 This doesn't sufficiently address the issue. 4298 The MED step in the decision process is (in 9.1.2.2): 4300 c) Remove from consideration routes with less-preferred 4301 MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable 4302 between routes learned from the same neighboring AS. Routes which do 4303 not have the MULTI_EXIT_DISC attribute are considered to have the 4304 lowest possible MULTI_EXIT_DISC value. 4306 This is also described in the following procedure: 4308 for m = all routes still under consideration 4309 for n = all routes still under consideration 4310 if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) 4311 remove route m from consideration 4313 In the pseudo-code above, MED(n) is a function which returns the 4314 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4315 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4316 MULTI_EXIT_DISC value, i.e. 0. 4318 Similarly, neighborAS(n) is a function which returns the neighbor AS 4319 from which the route was received. 4321 The problem is that a route loop can be formed. 4323 To avoid the route loop, two suggestions were made (2-3 years ago and 4324 nothing was done). One was to make MED(n) return infinity if there 4325 was no MULTI_EXIT_DISC. The other was to consider MULTI_EXIT_DISC in 4326 the decision process only for the purpose of selecting among the EBGP 4327 peers, then remove MULTI_EXIT_DISC, then use that best route in 4328 comparisons to IBGP learned routes. 4330 The statement in 5.1.4 "This MAY be done prior to determining the 4331 degree of preference of the route and performing route selection 4332 (decision process phases 1 and 2)" does not sufficiently address 4333 this. This implies that you MAY also remove after route selection, 4334 in which case field experience indicates you WILL get burned (unless 4335 you know about the caveat above). Initially this came up as an 4336 interoperability issue but later it was proven (in the field) that a 4337 Cisco and another Cisco could form a route loop until Cisco made this 4338 change. 4340 Additional wording is needed either in 5.1.4 or in 9.1.2.2. I 4341 suggest we put a forward reference in 5.1.4: 4343 [...]. This MAY be done prior to determining the degree of preference 4344 of the route and performing route selection (decision process phases 4345 1 and 2). See section 9.1.2.2 for necessary restricts on this. 4347 Then in 9.1.2.2 add a clarification to the neighborAS(n) function and 4348 add to the existing text. 4350 Similarly, neighborAS(n) is a function which returns the neighbor AS 4351 from which the route was received. If the route is learned via IBGP, 4352 it is the neighbor AS from which the other IBGP speaker learned the 4353 route, not the internal AS. 4355 If a MULTI_EXIT_DISC attribute is removed before redistributing a 4356 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4357 in the comparison of EBGP learned routes, them removed, then the 4358 remaining EBGP learned route may be compared to the remaining IBGP 4359 learned routes, without considering the MULTI_EXIT_DISC attribute for 4360 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4361 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4362 learned route in the comparison with an IBGP learned route, then 4363 dropping the MULTI_EXIT_DISC and advertising the route has been 4364 proven to cause route loops. 4366 The loop is the classic I prefer your and you prefer mine problem. 4367 It occurs when the router is configured to remove MULTI_EXIT_DISC and 4368 advertise out a route so other routers can use IGP cost to select the 4369 best route. If two routers do this, as soon as they hear the route 4370 with no MULTI_EXIT_DISC from the other peer they start forwarding 4371 toward that peer but they continue to advertise to it since others 4372 IBGP peers are expected to select among the MULTI_EXIT_DISC free IBGP 4373 learned routes using the next step in the decision process, IGP cost. 4375 In this case, what you want is each router to prefer its own EBGP 4376 route, even though it has a MULTI_EXIT_DISC and the IBGP learned 4377 route from the same neighbor AS has had its MULTI_EXIT_DISC stripped 4378 off (or didn't have one, you can't tell which it is). You then want 4379 all of the IBGP peers with a MULTI_EXIT_DISC free route from that AS, 4380 or that have stripped the MULTI_EXIT_DISC to form one, to advertise 4381 them. Others in the AS will then use IGP cost to further resolve 4382 which exit point to use. It make a difference when the route is the 4383 aggregate route of another major provider. IGP cost yields what ISPs 4384 call "hot potatoe routing" and MED selects among multiple heavily 4385 loaded provider interconnects. 4387 [Aside: Having a missing MULTI_EXIT_DISC default to infinity would do 4388 exactly what the ISPs want it to do in the first place and be a lot 4389 easier to explain but we didn't fix that 2-3 years ago when the issue 4390 came up even though we had WG consensus that it was the right thing 4391 to do. The authors didn't act on it at the time (because Cisco 4392 didn't do it that way and the authors preferred to sit on the draft). 4393 At this point we might as well adequately document what we ended up 4394 with.... End of soap box. I don't take myself all that seriously so 4395 others shouldn't either. :-)] 4397 After some more discussion on this, we have this text: 4399 In 5.1.4 replace: 4401 An implementation MAY also (based on local configuration) alter the 4402 value of the MULTI_EXIT_DISC attribute received over EBGP. If it 4403 does so, it shall do so prior to determining the degree of preference 4404 of the route and performing route selection (decision process phases 4405 1 and 2). 4407 with: 4409 An implementation MAY also (based on local configuration) alter the 4410 value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY 4411 be done prior to determining the degree of preference of the route 4412 and performing route selection (decision process phases 1 and 2). See 4413 section 9.1.2.2 for necessary restricts on this. 4415 In 9.1.2.2 replace: 4417 Similarly, neighborAS(n) is a function which returns the neighbor AS 4418 from which the route was received. 4420 with: 4422 Similarly, neighborAS(n) is a function which returns the neighbor AS 4423 from which the route was received. If the route is learned via IBGP, 4424 and the other IBGP speaker didn't originate the route, it is the 4425 neighbor AS from which the other IBGP speaker learned the route. If 4426 the route is learned via IBGP, and the other IBGP speaker originated 4427 the route, it is the local AS. 4429 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 4430 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4431 in the comparison of EBGP learned routes, then removed, then the 4432 remaining EBGP learned route may be compared to the remaining IBGP 4433 learned routes, without considering the MULTI_EXIT_DISC attribute for 4434 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4435 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4436 learned route in the comparison with an IBGP learned route, then 4437 dropping the MULTI_EXIT_DISC and advertising the route has been 4438 proven to cause route loops. 4440 There have been no objections to this, so we are at consensus. 4442 2.64 MED for Originated Routes 4444 Status: Consensus 4445 Change: No 4446 Summary: The consensus is that there is not need to specify default 4447 values for MED in the base draft. 4449 Discussion: 4451 This issue began when it was pointed out that we do not specify the 4452 default values for MED in the base draft. 4454 There were a variety of responses, but the consensus is that since 4455 this is not relevant for interoperability, this does not need to be 4456 in the base spec. 4458 2.65 Rules for Aggregating with MED and NEXT_HOP 4460 Status: Consensus 4461 Change: Yes 4462 Summary: Clear up the text on aggregating with a MED. See the 4463 discussion for the text. 4465 Discussion: 4467 There is a proposal to relax this statement: 4469 "Routes that have the following attributes shall not be aggregated 4470 unless the corresponding attributes of each route are identical: 4471 MULTI_EXIT_DISC, NEXT_HOP." 4473 In his reply to the original mail, Curtis asserted that we should 4474 leave the MED rules alone, but perhaps we could relax the NEXT_HOP 4475 statement. 4477 This was revisited in the "aggregating with MED and NEXT_HOP" thread. 4479 Yakov suggested we replace: 4481 Routes that have the following attributes shall not be aggregated 4482 unless the corresponding attributes of each route are identical: 4483 MULTI_EXIT_DISC, NEXT_HOP. 4485 If the aggregation occurs as part of the update process, routes with 4486 different NEXT_HOP values can be aggregated when announced through an 4487 external BGP session. 4489 Path attributes that have different type codes can not be aggregated 4490 together. Path attributes of the same type code may be aggregated, 4491 according to the following rules: 4493 with: 4495 Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be 4496 aggregated. 4498 Path attributes that have different type codes can not be aggregated 4499 together. Path attributes of the same type code may be aggregated, 4500 according to the following rules: 4502 NEXT_HOP: When aggregating routes that have different NEXT_HOP 4503 attribute, the NEXT_HOP attribute of the aggregated route SHALL 4504 identify an interface on the router that performs the aggregation. 4506 This met with agreement. 4508 Dimitry asked if the "Routes that have different MULTI_EXIT_DESC 4509 attribute SHALL NOT be aggregated." sentence was unnecessary since it 4510 should be a matter of local policy. Jeff replied that it has been 4511 mentioned that removing this stipulation can cause routing loops. 4513 We are at consensus with this issue. 4515 2.66 Complex AS Path Aggregating 4516 Status: Consensus 4517 Change: No 4518 Summary: Since we have two implementations of this method, section 4519 6.8 stays in the specification. 4521 Discussion: 4523 Jonathan opened this discussion with: 4525 The part in the draft about complex AS path aggregation could/should 4526 be deleted. The current draft implies that when aggregating, for 4527 example (1st): 4529 1 2 4 3 4531 w/ 4533 3 4 6 5 4535 and 4537 5 6 7 8 4539 then 4541 1 2 {3 4 5 6} 7 8 4543 ...would be OK 4545 AFAIK, all implementations aggregate by either: (2nd)putting ONLY the 4546 local AS in the path (and setting the atomic) OR (3rd)by creating 1 4547 giant set and adding the local AS as a seq. 4549 So he proposed we remove this to reflect current code. 4551 Jeff replied that there is absolutely nothing wrong with doing 4552 complex aggregation, and there is no reason to remove this from the 4553 specification. 4555 Yakov responded that: 4557 Jonathan is certainly correct that the spec has to reflect current 4558 code. Therefore, unless there are at least two (interoperable) 4559 implementations that implement the algorithm described in "6.8 4560 Complex AS_PATH aggregation", this section has to be removed (this is 4561 irrespective of whether there is something wrong, or nothing wrong 4562 with complex aggregation). With this in mind, if you implement this 4563 algorithm please speak up within a week. If within a week we 4564 wouldn't know that there are at least two implementations the section 4565 will be removed. And likewise, if we hear that there are at least two 4566 implementations, the section will stay. 4568 Jeff replied: 4570 I am also fine with removing it. I just don't think its necessary, 4571 especially if One Of These Days someone decides that running policy 4572 based on as-adjacencies would be a Nice Thing and fixes their 4573 implementation to support "complex" aggregation of paths. 4575 That said, I am aware of no one who implements this. 4577 As an aside, in the thread "last thought on complex aggregation" Jeff 4578 supplied: 4580 I finally remembered what was bothering me about removing complex 4581 aggregation from the spec. 4583 If it is removed, people who do conformance tests and some 4584 implementations may take this to mean "it shall be illegal to have an 4585 AS_PATH that contains a SEQUENCE of a particular type after a SET". 4587 This would make a perfectly ok AS_PATH into one that isn't legal, 4588 even if no implementation currently generates it. 4590 Jonathan replied that he thought the issue was moot since no one has 4591 implemented this. 4593 John replied that, although he is a bit uncomfortable in removing 4594 this from the spec, he doesn't see any harm in doing so. 4596 With this in mind, Yakov suggested we consider the issue closed. 4598 So we will wait a week from 10/17 to see if anyone chimes in. 4600 Siva responded that they have implemented this functionality. So we 4601 need one more...Ben responded that they support this at Marconi as 4602 well. 4604 So we have two implementations, the section stays in the spec. We 4605 are at consensus with this issue. 4607 2.67 Counting AS_SET/AS_CONFED_* 4609 Status: Consensus 4610 Change: Yes 4611 Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to 4612 the BGP Confederations document. Update the base draft to reflect 4613 this by changing section 9.1.2.2. Specific text is at the end of the 4614 discussion. 4616 Discussion: 4618 Jonathan brought up some questions on how current implementations 4619 count AS_SET and AS_CONFED_* 4621 There were a variety of responses to this, answering his questions. 4622 Curtis pointed out that this behavior is covered in: 4624 That's in 9.1.2.2: 4626 a) Remove from consideration all routes which are not tied for having 4627 the smallest number of AS numbers present in their AS_PATH 4628 attributes. Note, that when counting this number, an AS_SET counts as 4629 1, no matter how many ASs are in the set, and that, if the 4630 implementation supports [13], then AS numbers present in segments of 4631 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4632 count of AS numbers present in the AS_PATH. 4634 Jonathan replied that this might be at odds with what Juniper does, 4635 although he was unsure, and asked for clarification. 4637 This was discussed in the "New Issue AS path" thread. 4639 Yakov proposed that: 4641 The issue of route selection in the present of confederations belongs 4642 *not* to the base spec, but to the spec that describes BGP Confeds. 4643 With this in mind I would suggest to change in 9.1.2.2 from 4645 a) Remove from consideration all routes which are not tied for having 4646 the smallest number of AS numbers present in their AS_PATH 4647 attributes. Note, that when counting this number, an AS_SET counts as 4648 1, no matter how many ASs are in the set, and that, if the 4649 implementation supports [13], then AS numbers present in segments of 4650 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4651 count of AS numbers present in the AS_PATH. 4653 to 4655 a) Remove from consideration all routes which are not tied for having 4656 the smallest number of AS numbers present in their AS_PATH 4657 attributes. Note, that when counting this number, an AS_SET counts as 4658 1, no matter how many ASs are in the set. 4660 and ask the authors of BGP Confeds to update their document to cover 4661 how the presence of confeds impact route selection. 4663 This met with agreement, this issue is at consensus. 4665 2.68 Outbound Loop Detection 4667 Status: Consensus 4668 Change: No 4669 Summary: The consensus is, that while this may be a useful technique, 4670 it would break existing methods, and is otherwise out-of-scope for 4671 the base draft. It was suggested that this could be addressed in the 4672 update to RFC1772. 4674 Discussion: 4676 Jonathan brought up that: 4678 This paper (thanks Jeff) 4679 http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR- 4680 TR-2000-08 indicates that it is better to do the loop detection 4681 outbound as well inbound. The current draft indicates that it only 4682 needs to be done inbound. IOS does it inbound as well as outbound. 4683 GateD/Juniper does it (did it ???) only inbound. 4685 So I propose we add: "An implementation MAY choose to not advertise 4686 routes to EBGP peers if these routes contain the AS of that peer in 4687 the AS path." after: "If the autonomous system number appears in the 4688 AS path the route may be stored in the Adj-RIB In, but unless the 4689 router is configured to accept routes with its own AS in the AS path, 4690 the route shall not be passed to the BGP Decision Process." 4692 *If there is at least one other implementation that does outbound 4693 pruning/loop-detection.* 4695 Yakov pointed out that this is ONLY applicable to the base draft if 4696 there are multiple implementations doing this. This issue will only 4697 be considered if these implementors come forward by 10/25/02. 4698 Otherwise the issue will be considered closed. 4700 Jeff replied that there was more at stake with this than if people 4701 had implemented it: 4703 My suggestion is that this can stay out of the base draft. While it 4704 is true that this speeds up convergence (per the paper), it doesn't 4705 affect interoperability. 4707 Also, adding this specifically removes the ability from several 4708 implementations to be able to bridge a partitioned AS by permitting 4709 loops. (I'm not going to argue whether this is a Good way to do 4710 this, just that its done.) 4712 Its also worth noting that one could produce the same resultant 4713 speed-up by detecting the loop on an outbound basis and *not* 4714 applying the min*timers to the UPDATE. Thus, this would be a case 4715 of an advertisement of NLRI being treated the same, timer-wise, as 4716 the advertisement of WD_NLRI. 4718 I would suggest moving this suggestion for outbound loop detection 4719 in one form or another to the 1772 replacement. 4721 Yakov agreed with this. 4723 2.69 Appendix A - Other Documents 4725 Over the course of this discussion, a number of issues have been 4726 raised that the group though would be better dealt with in other 4727 documents. These additional documents, and their concomitant issues 4728 will be more fully addressed when the WG turns its focus to them. 4729 These projects are: 4731 1) Update RFC 1772: Application of the Border Gateway Protocol in the 4732 Internet. This will probably entail a complete rewrite. 4734 2) Update Route Reflector (2796) and Confederation (3065) RFC's 4735 regarding their impact on route selection. 4737 3) Write a new document covering BGP Multipath. 4739 3. The Issues from -18 to -19. 4741 This section lists the issues discussed on the list from November 4742 2002 to late February 2003. 4744 3.1 Reference to RFC 1772 4746 Status: Consensus 4747 Change: No 4748 Summary: Proposed changing RFC 1772 reference, since that document 4749 should be updated. 4751 Discussion: 4753 Jeff proposed that we reconsider referencing RFC 1772, since that 4754 document should be updated. 4756 Yakov pointed out that this is a non-normative reference and can just 4757 be left as is. 4759 Jeff agreed that this wasn't a big deal. We are at consensus to 4760 leave things as they are. 4762 This was discussed in the "-18 last call comments" thread. 4764 3.2 MUST/SHOULD Capitalization 4766 Status: Consensus 4767 Change: Yes 4768 Summary: Capitalize MUST/SHOULD where appropriate. 4770 Discussion: 4772 Jeff brought this up, and Yakov responded asking that he point out 4773 specific instances where this is needed. Jeff said he would do so, 4774 given some time. 4776 Yakov later replied that this would be fixed in the -19 version. 4778 Jeff replied with a master diff showing the MUST/SHOULDs, for the 4779 entire document please see the beginning of the thread entitled: 4780 "Issues list, #2: MUST/SHOULD Capitalization" 4782 This was discussed in the "18 last call comments" thread. This was 4783 also brought up in the "proxy: comments on draft -18" thread. 4785 3.3 Fix Update Error Subcode 7 -- accidently removed. 4787 Status: Consensus 4788 Change: Yes 4789 Summary: Add error subcode 7 back in, it looks like it was 4790 inadvertently removed. Add deprecation text to Open Message Error 4791 subcode 5. 4793 Discussion: 4795 Jeff supplied: 4797 Update message error subcode 7 is removed. Especially in -18, 4798 it looks like an editing mistake based on where it would fall 4799 in the editing.. 4801 Yakov mentioned that this is addressed in Appendix A. 4803 Jeff replied: 4805 What I would like to see is something like this: 4807 6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 - 4808 Invalid NEXT_HOP Attribute 4810 As it stands, 7 lies on a page boundary and looks like it got 4811 clipped by the roff. 4813 Yakov agreed, and also said he would add similar text for Open 4814 Message Error subcode 5. 4816 This was discussed in the "18 last call comments" thread. 4818 3.4 Section 5.1.4 - Editorial Comment 4820 Status: Consensus 4821 Change: Yes 4822 Summary: Fix "restricts" to "RESTRICTIONS" 4824 Discussion: 4826 Jeff proposed an editorial fix. This is agreed to. 4828 This was discussed in the "-18 last call comments" thread. 4830 3.5 Section 9.1 - Change "all peers" to "peers" 4832 Status: Consensus 4833 Change: Yes 4834 Summary: Section 9.1 - Change "all peers" to "peers" 4836 Discussion: 4838 Jeff proposed: 4840 9.1: The output of the Decision Process is the set of routes that 4841 will be advertised to (delete all) peers; the selected routes will 4842 be stored in the local speaker's Adj-RIB-Out according to policy. 4844 The previous wording implied that routes in the LocRib MUST be 4845 placed in the adj-rib-out. 4847 Yakov agreed, this fix will be in the next revision. 4849 This was discussed in the "-18 last call comments" thread. 4851 3.6 AS Loop Detection & Implicit Withdraws 4852 Status: Consensus 4853 Change: Yes 4854 Summary: Update the text to reflect the AS Loop detection should be 4855 done in the BGP decision process. 4857 Discussion: 4859 John brought this up, and suggested: 4861 I have one further comment just in case it's not perfectly obvious 4862 to everyone, which is that "ignore the UPDATE" is not strictly the 4863 action you take when receiving a looped update. Rather, you treat 4864 it as an implicit withdraw, i.e. you process it as any other update 4865 but treat the contained NLRI as unfeasible. 4867 I was going to write that this is sufficiently clear from the spec, 4868 but I regret to say that it isn't. Here is the fourth paragraph of 4869 section 9: 4871 The information carried by the AS_PATH attribute is checked for 4872 AS loops. AS loop detection is done by scanning the full AS path 4873 (as specified in the AS_PATH attribute), and checking that the 4874 autonomous system number of the local system does not appear in 4875 the AS path. If the autonomous system number appears in the AS 4876 path the route may be stored in the Adj-RIB-In, but unless the 4877 router is configured to accept routes with its own autonomous 4878 system in the AS path, the route shall not be passed to the BGP 4879 Decision Process. Operations of a router that is configured to 4880 accept routes with its own autonomous system number in the AS 4881 path are outside the scope of this document. 4883 I don't think this is quite right -- the decision process needs to 4884 be run if the looped routes had previously been advertised feasibly 4885 on the same session. This could be fixed by hacking the quoted 4886 paragraph, but it seems more straightforward to do it by removing 4887 the quoted paragraph and making the fix in 9.1.2 Phase 2 instead. 4888 This could be done by inserting the following between the third and 4889 fourth paragraphs of 9.1.2 Phase 2: 4891 If the AS_PATH attribute of a BGP route contains an AS loop, the 4892 BGP route should be excluded from the Phase 2 decision function. 4893 AS loop detection is done by scanning the full AS path (as 4894 specified in the AS_PATH attribute), and checking that the 4895 autonomous system number of the local system does not appear in 4896 the AS path. Operations of a router that is configured to 4897 accept routes with its own autonomous system number in the AS 4898 path are outside the scope of this document. 4900 Section 9.3, first bullet, also addresses this topic, but I don't 4901 think it's sufficient. 4903 Yakov agreed that this was a change for the better and will include 4904 this in the next revision. 4906 We are at consensus on this issue. 4908 This is discussed in the "-18 last call comments" thread. 4910 3.7 Standardize FSM Timer Descriptions 4912 Status: Consensus 4913 Change: Yes 4914 Summary: Standardize the state descriptions on those listed in the 4915 discussion section of this issue. 4917 Discussion: 4919 Tom proposed: 4921 I think a standard description would serve us better instead of 4922 using the following different ways (which I take all to refer to 4923 the same entity): 4925 delayBGP open timer 4926 BGP delay open timer 4927 BGP open delay timer 4928 delay open timer 4929 BGP delay timer 4931 I suggest Open Delay timer (with those capitals) 4933 I believe that the corresponding flag is consistently referred to 4934 (apart from the capitalization) as Delay Open flag 4936 Yakov agreed with this suggestion, no one else disagreed, we are at 4937 consensus. 4939 This was discussed in the "BGP18-FSM-terminology" thread. 4941 3.8 FSM MIB enumerations 4943 Status: Consensus 4944 Change: Yes 4945 Summary: Move MIB references from the base spec into the MIB 4946 document. 4948 Discussion: 4950 Tom pointed out that: 4952 The FSM makes several references to putting values into MIB objects 4953 and while some of the values are defined, eg FSM error or Hold Timer 4954 expired, I can find no definition of the following in any of the BGP 4955 documents, MIB or otherwise. 4957 connect retry expired 4958 TCP disconnect 4959 administrative down 4960 collision detect closure 4961 Call Collision cease 4962 collision detected and dump connection 4963 Administrative stop 4965 I believe an implementation needs to be told these values somewhere 4966 and that there should be a reference to that place in bgp18. 4968 Jeff replied that to make things easier, the MIB references will be 4969 removed from the base spec, and into the MIB document. 4971 This was discussed in the "WG Last Call FSM MIB enumeration" thread, 4972 and the "bgp18 WG Last Call fsm MIB objects" thread. 4974 3.9 Make "delete routes" language consistent 4976 Status: Consensus 4977 Change: Yes 4978 Summary: Replace a variety of wording with "deletes all routes 4979 associated with this connection,". 4981 Discussion: 4983 Tom pointed out that we use a variety of language to say how we are 4984 going to delete routes in the FSM. He proposed that we instead use: 4986 - deletes all routes associated with this connection, 4988 This met with agreement, and will be reflected in the next version. 4990 This was discussed in the "bgp18 WG Last Call fsm delete action" 4991 thread. 4993 3.10 Correct OpenSent and OpenConfirm delete wording 4995 Status: Consensus 4996 Change: Yes 4997 Summary: Remove delete wording from OpenSent and OpenConfirm states. 4999 Discussion: 5001 Venu asked why there was delete wording in the OpenSent and 5002 OpenConfirm states when a BGP speaker cannot receive routes in these 5003 states. 5005 Jeff acknowledged that this was an error. Yakov agreed to fix the 5006 next version. 5008 This was discussed in the "bgp18 WG Last Call fsm delete action" 5009 thread. 5011 3.11 Incorrect next state when the delay open timer expires. 5013 Status: Consensus 5014 Change: Yes 5015 Summary: Fix the next state. 5017 Discussion: 5019 Tom pointed out that: 5021 I believe that there is an incorrect next state when the delay open 5022 timer expires [event 12] in the Active state. The next state should 5023 be OpenSent and not OpenConfirm. 5025 OpenConfirm is for KeepAlive processing when Open messages have been 5026 sent and received. 5028 OpenSent is for Open sent and not yet received. 5030 The corresponding section in Connect state I believe is correct. 5032 Yakov agreed, and will fix this in the next revision. 5034 This was discussed in the "bgp18 WG Last Call fsm incorrect next 5035 state" 5037 3.12 Entering OpenConfirm / Adding "Stop OpenDelay" action 5039 Status: Consensus 5040 Change: Yes 5041 Summary: Add this text: 5043 Change 2 - 5044 Connect state 5045 event 17 (currently defined as going to Active) 5046 event 9 (stays in Connect state) 5048 new Text: 5050 In response to the connect retry timer expires event [Event 5051 9], the local system: 5052 - drops the TCP connection, 5053 - restarts the connect retry timer, 5054 - stops the Open Delay timer and resets the timer to zero, 5055 - initiates a TCP connection to the other BGP peer, 5056 - continues to listen for a connection that may be 5057 initiated by the remote BGP peer, and 5058 - stays in Connect state. 5060 If the TCP connection fails [Event17], the local system: 5061 - restarts the connect retry timer, 5062 - stops the Open Delay timer and resets value to zero, 5063 - continues to listen for a connection that may be 5064 initiated by the remote BGP peer, and 5065 - changes its state to Active. 5067 Further discussion on Keepalives has been moved to issue 52. 5069 Discussion: 5071 This discussion began with Tom outlining these two points: 5073 When the OpenConfirm state is entered from OpenSent with the receipt 5074 of a valid open [Event 18], then a KeepAlive message is sent and the 5075 timer is started. 5077 When the OpenConfirm state is entered from Active or Connect on 5078 receipt of a valid open [Event 19], no message is sent, no timer is 5079 started. 5081 I believe this inconsistency is an error and should be corrected by 5082 adding these two actions in those two places. 5084 Sue replied: 5086 Just to clarify this comment: 5088 Event 19 = valid open with delay timer running 5090 Active = 1) awaiting TCP connection, or 5091 2) TCP connection completed and awaiting the 5092 TCP connection with delay timer running 5094 Case 1: - should not see Event 19 5095 In transition from Active to Open Confirm, the connection 5096 must have a TCP connection completed. Case 1 does not 5097 have this occurring, so the transition must be avoided. 5099 Case 2: - should see Event 19 5101 - Open, Keepalive should be sent. 5103 Previous text: (Action H from FSM document) 5105 If an Open is received with the BGP Delay Open timer running, 5106 [Event 19], the local system: 5107 - clears the connect retry timer [cleared to zero), 5108 - completes the BGP initialization, 5109 - stop and clears the BGP Open Delay timer, 5110 - Sends an Open Message, 5111 - sets the hold timer to a large value (4 minutes), and 5112 - changes its state to an Open Confirm. 5114 New text: [a New Action - N-2 : N + BGP keepalive sent] 5116 If an Open is received with the BGP Delay Open Timer running 5117 [Event 19], the local system: 5118 - clear the connect retry timer [cleared to zero], 5119 - completes the BGP initialization, 5120 - stops and clears the BGP Open Delay timer, 5121 - Send an Open message, 5122 - Sends a Keepalive message, 5123 - If hold timer value is non-zero, 5124 - set keepalive timer 5125 - hold timer reset to negotiated value 5126 else if hold timer is zero, 5127 - reset the keepalive timer, and 5128 - reset the hold timer. 5130 - If the value of the autonomous system field is the 5131 same as the local Autonomous system number, set 5132 the connection status to a internal connection; 5133 otherwise it is "external". 5135 Tom and Sue discussed the OpenDelay state, and recalled that this was 5136 excluded a number of months ago as not reflecting current practice. 5138 By way of clarification, Sue added: 5140 1) Agree, this can occur in the Active state as well as the 5141 Connect state. Will you accept the earlier text below 5142 to be inserted both places? 5144 Background: 5146 The state machine for Event 19 is: 5148 Idle Connect Active Open Open Estb 5149 Sent Confirm 5150 ================================================ 5151 Event 19 | | | | | | | 5152 next state |Idle | Open | Open | Open |Idle | Idle | 5153 | | confirm| confirm| Confirm| | | 5154 ================================================ 5155 action | V | N-2 | N-2 | N | E-1 | E | 5156 ================================================ 5158 Per the State Machine. 5160 Action v - FSM Error 5161 Action E - FSM Error, drop connection - etc, drop routes 5162 Action E-1 - FSM Error, drop connection (lots of 5163 Action N-2 (text below) 5164 Action N (text below, without sending Open) 5166 2) Do you think that Event 19 is possible in the Open Sent state? 5168 Please answer this separately. 5170 Tom replied that: 5172 1) yes I think the same text in both Active and Connect states is a 5173 good resolution 5175 2) complicated. As the fsm text stands, Event 19, along with a 5176 host of others, takes us back from Open Sent to Idle (I assume on 5177 the grounds this is an error condition) which seems very reasonable. 5179 But ...in quite a few places, such as Connect state events 2, 5180 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer 5181 when going to Idle or Active so we could then go from eg Idle with 5182 Manual start [event 1] to Connect to Open Sent all before the 5183 OpenDelay timer expires in which case event 19 can occur validly in 5184 Open Sent - obscure but possible. (This is also true with Active 5185 state and events 2, 17 and the default list at the end). 5187 But I think this is an error, and that when exiting Connect state or 5188 Active state as listed above, we should have an additional action to 5189 stop the OpenDelay timer in which case event 19 in Open Sent becomes 5190 an error condition (again). 5192 But but but as ever, I cannot speak with authority for 5193 implementations and so if implementations do not stop the OpenDelay 5194 timer when exiting as above, then Event 19 is valid in Open Sent 5195 state - obscure but possible (again). 5197 My wish is to add the extra action, stop OpenDelay timer, for the 5198 events listed above in Active and Connect states in the expectation 5199 that that is what people have or should have implemented. 5201 Tom added a response to Sue after some other threads have been 5202 discussed: 5204 You asked if event 19 (Open with OpenDelay timer running) was 5205 possible in OpenSent state; I gave a lengthy reply (below) to the 5206 effect yes it could because the OpenDelay timer did not always get 5207 stopped but the timer should be stopped in which case the event 5208 would not happen. 5210 Reading your responses to Siva , I see you include stopping the Open 5211 Delay timer in the action 'release all BGP resources' when going to 5212 Idle (which I missed seeing earlier in the year). 5214 That eliminates most but not all of the possibilities I mentioned. 5215 I now believe we would need to add the action 'stop OpenDelay timer' 5216 for 5218 Connect state 5219 event 17 (currently defined as going to Active) 5220 event 9 (stays in Connect state) 5222 in order to stop event 19 in Open Sent 5224 Sue replied that, she thought this was at consensus, and provided the 5225 new text, which is: 5227 Change 1: new text 5229 Active state - event 19 5231 If an Open is received with the Open Delay timer is 5232 running [Event 19], the local system 5233 - clears the connect retry timer (cleared to zero), 5234 - stops and clears the Open Delay timer 5235 - completes the BGP initialization, 5236 - stops and clears the Open Delay timer 5237 - sends an OPEN message, 5238 - send a Keepalive message, 5239 - if the hold timer value is non-zero, 5240 - starts the keepalive timer to initial value, 5241 - resets the hold timer to the negotiated value, 5242 else if the hold timer is zero 5243 - resets the keepalive timer (set to zero), 5244 - resets the hold timer to zero. 5246 - changes its state to OpenConfirm. 5248 If the value of the autonomous system field is the same as the 5249 local Autonomous System number, set the connection status to 5250 an internal connection; otherwise it is "external". 5252 Change 2 - 5253 Connect state 5254 event 17 (currently defined as going to Active) 5255 event 9 (stays in Connect state) 5257 new Text: 5259 In response to the connect retry timer expires event [Event 5260 9], the local system: 5261 - drops the TCP connection, 5262 - restarts the connect retry timer, 5263 - stops the Open Delay timer and resets the timer to zero, 5264 - initiates a TCP connection to the other BGP peer, 5265 - continues to listen for a connection that may be 5266 initiated by the remote BGP peer, and 5267 - stays in Connect state. 5269 If the TCP connection fails [Event17], the local system: 5270 - restarts the connect retry timer, 5271 - stops the Open Delay timer and resets value to zero, 5272 - continues to listen for a connection that may be 5273 initiated by the remote BGP peer, and 5274 - changes its state to Active. 5276 Tom replied that: 5278 Change 2, stop Open Delay timer in Connect state events 9 and 17, 5279 fine; that is what I understand to be the real issue 12. 5281 Change 1, event 19 in Active state, is IMHO issues 47 and 52. This 5282 is tangled because the initial paragraphs of Issue 12 in the issue 5283 list are nothing to to with stopping Open Delay timer and everything 5284 to to with sending a Keepalive message before entering Open Confirm 5285 state from Active or Connect state on event 19; which I raised and 5286 see as issue 52. Issue 47 was Siva's issue 28 and relates to a 5287 different action for Active state event 19. 5289 I agree with change 1 in that it adds in the sending of Keepalive 5290 which I believe essential; I think Siva needs to respond concerning 5291 issue 47. (nb the stop Open Delay action is duplicated) I wonder 5292 if we should use a different character for the bullet points under 5293 the if and else clauses to make it clear where they end ie 5294 - if the hold timer .... 5295 + do this 5296 + and this 5297 else if ... 5298 + do the other 5299 + and this 5301 But I still have an issue for Connect state event 19 where I 5302 believe, as for Active state event 19, we should send a Keepalive 5303 and start the Keepalive timer. I will pursue this as part of issue 5304 52 if that suits you. I think the text will be the same as whatever 5305 we agree for Active state event 19. 5307 This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" 5308 thread. And also in the "Event 19 in Open Sent state was Re: bgp18 5309 WG Last Call fsm missing keepalive" thread. This also came up in the 5310 "issues 12 - consensus & two changes - 2nd message" thread. 5312 3.13 FSM Missing Next States 5314 Status: Consensus 5315 Change: Yes 5316 Summary: Seven sub-issues spawned to resolve each of the next-state 5317 questions. See each sub-issue for specifics. 5319 Discussion: 5321 This began with Tom pointing out 7 places where the next state was 5322 not clear. Interlaced with his comments below is the proposed text 5323 to fix the problems and the status of the issue. 5325 All sub-issues are at consensus. 5327 This conversation was started in the "bgp18 WG Last Call fsm missing 5328 next state" thread. 5330 3.13.1 FSM Missing Next States - Event 15 or 16 (Connect State) 5331 Status: Consensus 5332 Change: Yes 5333 Summary: Add next state of Connect. 5335 Discussion: 5337 Tom pointed out that: 5339 Connect State: 5341 If the TCP connection succeeds [Event 15 or 5342 Event 16], the local system checks the "Delay Open 5343 Flag". If the delay Open flag is set, the local system: 5344 **enters what state 5346 Sue proposed these changes: 5348 1) Connect State - Event 15 or Event 16 [consensus, editorial] 5350 note: The delay retry timer is utilized instead of the 5351 connect retry timer for the next two changes. 5353 Previous text: 5355 If the TCP connection succeeds [Event 15 or Event 16], 5356 local system checks the "Delay Open Flag". If the delay 5357 open flag is set, the local system: 5358 - clears the connect retry timer, 5359 - sets the BGP open delay timer to initial value 5361 If the Delay Open flag is not set, the local system: 5362 - clears the connect retry timer, 5363 - clear BGP Open Delay timer (set to zero), 5364 - completes the BGP initialization, 5365 - send an Open message to its peer, 5366 - sets hold timer to a large value, and 5367 - change the state to Open Sent. 5369 New text: 5371 If the TCP connection succeeds [Event 15 or Event 16], 5372 local system checks the Delay Open flag prior to 5373 processing: If the Delay Open flag is set, the local system: 5374 - clears the connect retry timer, 5375 - sets the BGP open delay timer to initial value, and 5376 - stays in the Connect state. 5378 If the Delay Open flag is not set, the local system: 5380 - clears the connect retry timer, 5381 - clears the BGP Delay timer (sets to zero), 5382 - completes the BGP initialization, 5383 - sends an Open message to its peer, 5384 - sets the hold timer to a large value, and 5385 - changes the state to Open Sent. 5387 Tom agreed that this was good, with the change to "Open Delay timer" 5388 as discussed in issue 7. 5390 This conversation was started in the "bgp18 WG Last Call fsm missing 5391 next state" thread. 5393 3.13.2 FSM Missing Next States - Event 14 (Connect State) 5395 Status: Consensus 5396 Change: Yes 5397 Summary: We selected option 2 from discussion as the correct text: 5399 2) treat it as an invalid response, reject the connection and see 5400 if a valid configured one comes within the connect timer's 5401 window. 5403 Discussion: 5405 Tom pointed out that: 5407 Connect State: 5409 If the TCP connection receives an indication 5410 that is invalid or unconfigured. [Event 14]: 5411 **enters what state 5413 Sue proposed these alternatives: 5415 2)Connect State - Event 14 [no consensus] 5417 Current Text: 5418 If the TCP connection receives an indication that 5419 that is invalid or unconfigured [Event 14], 5420 - the TCP connection is rejected. 5422 At the very least this section needs more "word smithing", 5423 so I'd like to change it for more clarity at least. 5425 I'm not sure this represents the implementations. 5426 What I'd like to do is query the implementations 5427 to see what they do if they receive a valid TCP 5428 connection with an invalid or unconfigured peer. 5430 Two options: 5432 Alternative 1: Count it as a valid response 5434 New Text: If a TCP connection is received that has 5435 an invalid format, or an unconfigured host [Event 14], 5436 the local system: 5437 - rejects the TCP connection, 5438 - increments the connect retry counter, 5439 - performs bgp peer oscillation checks. 5441 If bgp peer oscillation checks allow for a new 5442 connection, the bgp peer 5443 - restarts the Connect retry timer with configured 5444 value, and 5445 - enters the Active state. 5447 FSM table: 5448 Idle Connect Active Open-Sent Open-Confirm Establish 5449 Event-14 ======================================================= 5450 Next state Idle | Active|Active|Open-Sent|Open-Confirm|Establish| 5451 ======================================================= 5452 action V | Y2 | L | Ignore | Ignore | Ignore | 5453 ======================================================= 5455 Alternative 2: Reject the connection and see if valid or 5456 configured one appears within the 5457 connect timer window. 5459 New Text: If a TCP connection is received that has an invalid 5460 format, 5461 or an unconfigured host [Event 14], the local system: 5462 - rejects the TCP connection, 5463 - and stays in the Connect state. 5465 FSM table: 5466 Idle Connect Active Open-Sent Open-Confirm Establish 5467 Event-14 ======================================================= 5468 Nxt state Idle |Connect|Active|Open-Sent|Open-Confirm|Establish| 5469 ======================================================= 5470 action V | L | L | Ignore | Ignore | Ignore | 5471 ======================================================= 5473 Sue then sent out a call to implementors to let the list know what 5474 they did with their FSMs. Tom replied that he agreed that we need to 5475 wait to see what the existing implementations do. He also suggested: 5477 **tp need a then clause here 'if bgp peer oscillation damping does 5478 not allow for a new connection, then the local system ???' 5480 be added before the FSM table in option 1 of the proposed text. 5482 Sue prodded the list saying that: 5484 Should the peer: 5485 1) Treat it as a valid response, and enters the active state 5486 to watch for a another TCP connection with a valid peer. 5488 2) treat it as an invalid response, reject the connection and see 5489 if a valid configured one comes within the connect timer's 5490 window. 5492 Without further input, I will select option 2. 5494 Curtis replied that this was fine with him. 5496 There has been no further disagreement, we are at consensus on this. 5498 This conversation was started in the "bgp18 WG Last Call fsm missing 5499 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5500 input needed from developers" thread. 5502 3.13.3 FSM Missing Next States - Event 15 or 16 (Active State) 5504 Status: Consensus 5505 Change: Yes 5506 Summary: Add text listed in discussion. 5508 Discussion: 5510 Tom pointed out: 5512 Active State: 5514 A TCP connection succeeds [Event 15 or Event 16], the 5515 local system: process the TCP connection flags 5516 - If the BGP delay open flag is set: 5517 ** enters what state (I think this is an FSM error in TCP because it 5518 has not initiated a connection!) 5520 Sue proposed these changes: 5522 Previous text: 5524 A TCP connection succeeds [Event 15 or Event 16], 5525 the local system: process the TCP connection flags 5526 - If the BGP delay open flag is set: 5527 - clears the connect retry timer 5529 [through the following text: 5530 - and changes its state to Open Sent. 5532 New text: 5533 If the TCP connection succeeds [Event 15 or Event 16], 5534 local system checks the "Delay Open Flag" prior to 5535 processing: If the delay open flag is set, the local system: 5536 - clears the connect retry timer, 5537 - sets the BGP open delay timer to initial value, and 5538 - stays in the Active state. 5540 If the Delay Open flag is not set, the local system: 5541 - clears the connect retry timer, 5542 - clears the BGP Delay timer (sets to zero), 5543 - completes the BGP initialization, 5544 - sends an Open message to its peer, 5545 - sets the hold timer to a large value, and 5546 - changes the state to Open Sent. 5548 Tom agreed with this. 5550 This conversation was started in the "bgp18 WG Last Call fsm missing 5551 next state" thread. 5553 3.13.4 FSM Missing Next States - Event 13-17 (TCP Connection) 5555 Status: Consensus 5556 Change: Yes 5557 Summary: We selected: 5559 Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 5560 be mandatory. 5562 Discussion: 5564 Tom started this by saying that: 5566 If the local system receives a valid TCP Indication 5567 [Event 13], the local system processes the TCP connection 5568 flags. 5569 ** enters what state 5570 If the local system receives a TCP indication 5571 that is invalid for this connection [Event 14]: 5572 ** enters what state 5574 Sue proposed we move this to the "fsm missing next state - Events 5575 13-17 and the TCP connection" thread. 5577 The response in this thread was: 5579 4) Active State, Event 13 [no consensus] 5580 5) Active State, Event 14 [no consensus] 5582 The problem with this state is it is difficult to 5583 exactly specify without discussing the TCP 5584 Messages that FSM document covers. 5586 I'll query if the implementors require all 5587 of events 13-17 as mandatory. 5589 Sue polled the implementors on the list with this query: 5591 These events are described in section 8.1.3. 5593 In our discussion in January through May of 2002, many 5594 implementers mapped their implementation onto the 5595 following TCP events list in 8.1.3. 5597 Events 13 - 17 5599 Event 13 - TCP connection indication & valid 5600 remote peer 5602 Event 14 - TCP connection indication with invalid 5603 source or destination 5605 Event 15 - TCP connection request sent (by this 5606 peer) received an Acknowledgement 5608 [ local system sent a TCP SYN, Received a 5609 TCP SYN, ACK pair back, and Sent a TCP ACK] 5611 Event 16 - TCP connection confirmed 5613 [local system received a TCP SYN, sent 5614 a TCP SYN, ACK back, and received a TCP ACK] 5616 Event 17 - TCP connections 5618 Should we have all of these states? Which implementations 5619 support all of these Events? 5621 The full FSM text was snipped here for brevity. 5623 Sue prodded the list with: 5625 Do the implementors require Events 13 - 17 in the State machine ? 5627 Event 13 - TCP connection valid indication 5628 Event 14 - TCP connection invalid indication 5629 Event 15 - TCP connection request acknowledged 5630 Event 16 - TCP connection confirmed 5631 Event 17 - TCP connection fails 5633 Choice 1: Events 13 - 17 are mandatory 5634 Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 5635 be mandatory. 5637 If no one objects, we will use Choice 2. 5639 Curtis said this was fine with him. 5641 There has been no further disagreement, we are at consensus on this. 5643 This was started in the "bgp18 WG Last Call fsm missing next state" 5644 thread. And continued in the "fsm missing next state - Events 13-17 5645 and the TCP connection" thread. It was also discussed in the "BGP 5646 draft-19 - FSM input needed from developers" thread. 5648 3.13.5 FSM Missing Next States - Event 17 (Connect State) 5650 Status: Consensus 5651 Change: No 5652 Summary: Closed in favor of 13.4 5654 Discussion: 5656 If the local system receives a TCP connection 5657 failed [Event 17] (timeout or receives connection 5658 disconnect), the local system will: 5659 ** enters what state 5661 Sue replied with this: 5663 comment: In the Active state, we may already have a connection and 5664 be awaiting the Open Delay timer. The TCP disconnect or timeout 5665 could occur in this state due to the "Open Delay Timer". If the 5666 TCP Disconnect is ignored, we could have some peer oscillation. 5668 If the we wait, then the connection retry timer needs to be kept 5669 running. The text below allows this timer. The real question is 5670 what is the status of the current implementations. 5672 I agree, the Active state and the connect state should match. 5674 Old Text: 5675 If the TCP connection fails (timeout or disconnection) 5676 [Event 5677 17], the local system: 5678 - set TCP disconnect in the MIB reason code, 5679 - restart Connect retry timer (with initial value), 5680 - release all BGP resources, 5681 - Acknowledge the Drop of the TCP connection if TCP 5682 disconnect (FIN ACK), 5683 - Increment ConnectRetryCnt (connect retry count) by 5684 1, and 5685 - performs the BGP peer oscillation damping process. 5687 Applicable FSM State table: 5689 FSM table old: 5691 Event 17 5692 current: Idle Connect Active Open-Sent Open-Confirm Establish 5693 ========================================================= 5694 Next state Idle |Active |Idle |Active | Idle |Idle 5695 | 5696 | | | | | 5697 | 5698 ========================================================= 5699 action V | Y2 | G | Ignore| Track 2nd | Track 2nd 5700 | 5701 | | | | connection | 5702 connection| 5703 ========================================================= 5705 Alternative 1: 5707 FSM table new: 5709 Event 17 5710 current: Idle Connect Active Open-Sent Open-Confirm Establish 5711 ========================================================= 5713 Next state Idle |Active |Active |Active | Idle |Idle | 5714 | | | | | | 5715 ========================================================= 5716 action V | G | G | Ignore| Track 2nd | Track 2nd | 5717 | | | | connection | connection| 5718 ========================================================= 5720 G: The local system: 5721 - restarts the connect retry timer (at initial value), 5722 - continues to listen for a connection that may be initiated 5723 by the remote peer, and 5724 - sets its next state to Active. 5726 New Text: (for Connect and Active state) 5727 If the TCP connection fails (timeout or disconnect) 5728 [Event 17], the local system: 5729 - restarts the connect retry timer, 5730 - continues to listen for a connection that may be 5731 initiated by the remote BGP peer, and 5732 - changes it state to Active. 5734 Alternative 2: 5735 FSM table new: 5737 Event 17 5738 current: Idle Connect Active Open-Sent Open-Confirm Establish 5739 ========================================================= 5740 Next state Idle |Idle |Idle |Active | Idle |Idle 5741 | 5742 | | | | | 5743 | 5744 ========================================================= 5745 action V | Y2 | Y2 | Ignore| Track 2nd | Track 2nd 5746 | 5747 | | | | connection | 5748 connection| 5749 ========================================================= 5751 Next Text: 5752 If the location system receives a TCP connection failed 5753 [Event 5754 17], the local system will: 5755 - increment the ConnectRetryCnt (connect retry 5756 count) 5757 by 1, 5758 - release all BGP resources associated with this 5759 connection, 5760 - perform BGP peer oscillation (if configured), and 5761 - go to Idle 5763 Y2 - is: 5764 The local system: 5765 1) increments the ConnectRetryCnt (connect retry 5766 count) by 1, 5767 2) releases all BGP resources associated with this 5768 connection, and 5769 3) performs the BGP peer oscillation damping process 5771 if the damping process allows for a new connection, the 5772 local 5773 system: 5774 - restarts the connect retry timer (with initial 5775 value, and 5776 - goes to Idle 5778 If the damping process does not allow for a new connection, 5779 the local system 5780 - set the flags to damp the creation of a new bgp 5781 connection until a manual start occurs, and 5782 - goes to Idle. 5784 Tom agreed with the options, and stated that he preferred option 2. 5785 Sue is also happy with option 2, if no one else chimes in. 5787 After the issues list came out Tom responded to this issue, saying: 5789 I think this issue SHOULD be administratively terminated. 5791 It relates to Connect state Event 17 (TCP connection fails) and I am 5792 credited with raising it; in fact, the issue I raised was missing 5793 next state for Active state event 17 and this has now been subsumed 5794 into 13.4 (but note that 13.4 does not explicitly say Active state - 5795 I know it should because I raised that issue too). I will ensure it 5796 does not get lost from any resolution of 13.4. 5798 And Connect state event 17 does appear as part of issue 45 which 5799 Siva raised so I think that either way, 13.5 can go. 5801 This conversation was started in the "bgp18 WG Last Call fsm missing 5802 next state" thread. 5804 3.13.6 FSM Missing Next States - Event 18 (Open Confirm) 5806 Status: Consensus 5807 Change: Yes 5808 Summary: This is the text: 5810 In the Open Confirm state, a valid Open message [Event 22] is 5811 received. The BGP Peer connection is check to see if there is a 5812 collision per section 6.8. If this connection is to be dropped due 5813 to the call collision, the local system will drop the call by: 5815 - sending a NOTIFICATION with a CEASE, 5816 - resets the Connect timer (to zero), 5817 - releases all BGP resources (this includes stopping the Open 5818 Delay Timer 5819 and reseting it to zero), 5820 - increments the ConnectRetryCnt by 1 (connect retry +count), and 5821 - optionally performs a BGP peer oscillation damping processing, 5822 and 5823 - enters the Idle State. 5825 Discussion: 5827 Tom opened this with: 5829 Open Confirm State: 5831 If the Open messages is valid [Event 18], the collision 5832 detect function is processed per section 6.8. If this 5833 connection is to be dropped due to call collision, the 5834 local system: 5835 ** enters what state 5837 Sue replied with: 5839 Here's my proposed text. Please let me know what you think. 5840 I think this is an editorial change. 5842 Old text: If the open message is valid, the collision detect 5843 function is processed per section 6.8. If this 5844 connection is to be dropped due to call collision, the 5845 local system: 5846 - sends a Notification with a Cease 5847 - resets the Connect timer (to zero), 5848 - releases all BGP resources, 5849 - Drop the TCP connection (sends a TCP FIN), 5850 - increments the ConnectRetryCnt by 1 (connect retry 5851 count), and 5852 - performs an BGP peer oscillation damping process. 5854 New text: If the open message is valid, the BGP peer connection 5855 is check to detect a collision per section 6.8. If this 5856 connection is to be dropped due to call collision, the 5857 local system: 5858 - sends a Notification with a Cease 5859 - resets the Connect timer (to zero), 5860 - releases all BGP resources, 5861 - Drop the TCP connection (sends a TCP FIN), 5862 - increments the ConnectRetryCnt by 1 (connect retry 5863 count), and 5864 - performs an BGP peer oscillation damping 5865 processing, 5866 and 5867 - enters the Idle State. 5869 notes: Collision detect impacts Open Sent, Open Confirm, and 5870 Established states. 5872 Tom replied: 5874 I am still struggling with; we are in OpenConfirm so we already have 5875 received an Open from the remote peer and Event 18 is a second Open 5876 from the same peer. Perhaps my struggle is that I think in terms of 5877 two (or more) FSM for a given IP address pair so the Open Collision 5878 detection will occur when the/an- other FSM receives a valid Open in 5879 states Active/Connect/Open Sent and will generate Event 22 into this 5880 FSM so Event 18 cannot occur. But yes, if Event 18 can occur in 5881 this FSM and this connection is to be dumped, then Idle state it 5882 should be as you suggest. I have slotted in [optionally] in front 5883 of the peer oscillation damping in your text because I think it 5884 should be optional:-) 5886 Sue replied: 5888 this mechanism allows a single fsm to 5889 handle both. 2 fsm and 1 fsm BGP FSM 5890 seem to exist. (I queried implementors 5891 a few times on this one. So, I just 5892 put in this change to provide the 5893 flexibility. 5895 Collision detect tends to give 5896 scrambled brains for most people.. 5897 As Dennis Ferguson said 2 years ago, 5898 that's the hardest part of the FSM. 5900 Sue then stated that she would query implementors to see what is 5901 being done. 5903 Sue prodded the list with: 5905 In the Open Confirm state, a valid Open message [Event 22] is 5906 received. The BGP Peer connection is check to see if there is a 5907 collision per section 6.8. If this connection is to be dropped due 5908 to the call collision, the local system will drop the call by: 5910 - sending a NOTIFICATION with a CEASE, 5911 - resets the Connect timer (to zero), 5912 - releases all BGP resources (this includes stopping the Open 5913 Delay Timer 5914 and reseting it to zero), 5915 - increments the ConnectRetryCnt by 1 (connect retry +count), and 5916 - optionally performs a BGP peer oscillation damping processing, 5917 and 5918 - enters the Idle State. 5920 Implementors need to verify if this text and the text for Event 22 5921 allows all implementors to perform the necessary Call Collision 5922 actions. 5924 If no objects, we will use this text. 5926 Curtis said he had no problem with this. 5928 There has been no disagreement, we are at consensus with this. 5930 This conversation was started in the "bgp18 WG Last Call fsm missing 5931 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5932 input needed from developers" thread. 5934 3.14 FSM - Peer Oscillation Damping 5936 Status: Consensus 5937 Change: Yes 5938 Summary: Change references to peer oscillation damping to consistent 5939 phrase: 5940 "[optionally] performs peer oscillation damping". Also remove old 5941 reference to "BGP Peer Restart Backoff Mechanisms". 5943 Discussion: 5945 Tom suggested we use consistent terminology to refer to peer 5946 oscillation damping. He also pointed out a stale reference. 5948 Yakov agreed to fix both of these. 5950 3.15 FSM - Consistent FSM Event Names 5952 Status: Consensus 5953 Change: Yes 5954 Summary: Make FSM names consistent. Specifics are in the discussion 5955 section. 5957 Discussion: 5959 Tom proposed that: 5961 The event name used in the FSM show much variation to the point 5962 sometimes where I am not clear that it is always the same event (eg 5963 where the event name is qualified by a subset of the possible 5964 causes). Assuming that it is, I propose the following changes to 5965 make the wording consistent, clear and concise for event names. 5967 ** denotes changed text using the convention /'old text'/'new text'/ 5969 8. BGP Finite State machine 5971 Event1: Manual start 5972 Event2: Manual stop 5973 Event3: Automatic start 5974 **Event4: Manual start with passive TCP /establishment/flag/ 5975 **Event5: Automatic start with passive TCP 5976 /establishment/flag/ 5977 Event6: Automatic start with bgp_stop_flap option set 5978 **Event7: Auto//matic/ stop 5979 Event8: Idle hold timer expires 5980 Event9: Connect retry timer expires 5981 **Event10: Hold time//r/ expires 5982 Event11: Keepalive timer expires 5983 Event12: Open Delay timer expires 5984 **Event13: TCP connection valid indication 5985 **Event14: TCP connection invalid indication 5986 **Event15: TCP connection request /sent received an 5987 ACK/acknowledged/ 5988 Event16: TCP connection confirmed 5989 Event17: TCP connection fails 5990 Event18: BGPOpen 5991 Event19: BGPOpen with *Open Delay timer running 5992 Event20: BGPHeaderErr 5993 Event21: BGPOpenMsgErr 5994 Event22: Open collision dump 5995 Event23: NotifMsgVerErr 5996 Event24: NotifMsg 5997 Event25: KeepAliveMsg 5998 Event26: UpdateMsg 5999 Event27: UpdateMsgErr 6001 8.2.2 Finite State Machine 6003 Connect State: 6005 If the BGP port receives a ** valid TCP connection 6006 indication 6007 [Event 13], 6009 If the TCP connection receives **an invalid indication 6010 [Event 14]: 6012 If the TCP connection fails **/(timeout or disconnect)// 6013 [Event17] 6015 Active State: 6017 If the local system receives a **valid TCP //indication/ 6018 [Event 13], 6020 If the local system receives a TCP connection failed [Event 6021 17] **/(timeout or receives connection disconnect)//, 6023 Open Sent: 6025 If a connection in Open Sent is determined to be the 6026 connection that must be closed, an **/administrative 6027 collision 6028 detect/Open collision dump/ [Event 22] is signaled to the 6029 state machine. If such an **/administrative collision detect 6030 dump [Event 22]/event/ is 6032 If a TCP **//connection valid/ indication [Event 13] or 6033 TCP **//connection/ request **//acknowledged/ [Event 15] 6035 Open Confirm State: 6037 ...or receives a TCP **/Disconnect// connection fails/ 6038 [Event 6039 17] from the 6041 In the event of **/TCP establishment//TCP connection valid 6042 indication /[Event 13] 6044 ...the local system will 6045 **/issue a call/generate an Open/ collision dump [Event 22]. 6046 When the local system receives a **/call/open/ collision 6047 dump 6048 event [Event 22]/such an event/, the 6050 Established State: 6052 **/disconnect from the underlying TCP/TCP connection fails/ 6053 [Event17], it: 6055 ... it will process **/a Call/an Open/ Collision dump 6056 event[Event 22]. 6058 Notes: 6059 Event 4 title brought in line with text 6060 Event 5 title brought in line with text 6061 Event 7 title brought in line with text 6062 Event 13 title shortened to be closer to text, text brought in line 6063 Event 14 title shortened to be closer to text, text brought in line 6064 Event 15 title brought in line with text 6065 Event 17 text brought in line with title (text often introduces 6066 qualifying conditions that are too restrictive) 6067 Event 22 text brought in line with title 6069 Sue replied: 6071 I will accept the text you proposed for the Event names. 6072 I will update the FSM text to include your changes. 6074 We'll consider issue 15 in consensus. I've fixed the text. 6076 So we are at consensus here. 6078 This is discussed in the thread: "bgp18 WG Last Call fsm event 6079 names." It was also discussed in the "Issue 15 - Consistent FSM 6080 Event Names" thread. 6082 3.16 Many Editorial Comments 6084 Status: Consensus 6085 Change: Yes 6086 Summary: Many editorial suggestions, and what we are doing with them 6087 are listed below. Some issues have been broken out separately where 6088 there is a longer discussion on them. 6090 Discussion: 6092 Alex began this by presenting comments from an anonymous reviewer, 6093 unless otherwise noted, responses are from Yakov: 6095 > Almost all of these are simple clarifications. 6096 > 6097 > Section 1, page 5: IGP definition - it's not clear from this 6098 > definition whether IBGP would be considered an IGP? 6100 any suggestion on how to improve the definition to clarify 6101 this issue would be appreciated. 6103 There was some further discussion on this and it was decided that 6104 people reading this document ought to know what an IGP is. 6106 > Section 3, page 7, para 4: Does RFC 1772 still represent the 6107 > *planned* use of BGP? Or the actual use? Or something 6108 > different from actual use? 6110 Perhaps we should just take out references to 1772. 6112 Further discussion seemed to indicate that this reference should 6113 stay. 6115 > Section 3, page 8, para 3 - "The hosts executing..." This 6116 > paragraph seems obsolete. 6118 I'll take it out. 6120 With regard to this, Siva asked if some route optimization vendors 6121 rely on this. Since this wasn't resolved, it is discussed further in 6122 issue 17. 6124 > Section 4.1, page 11 - Length is in network byte order. 6126 all the encodings are in network byte order. This applies not just 6127 to the BGP spec, but to other protocols as well. 6129 This comment was made about a number of fields. It was later agreed 6130 that a reference would be made to this at the beginning of the 6131 document. 6133 > Section 4.2, page 12 - Hold Time - what does a value of zero 6134 > indicate? 6136 if you read section 4.4 then you'll find that: 6138 If the negotiated Hold Time interval is zero, then periodic 6139 KEEPALIVE messages MUST NOT be sent. 6141 > Section 4.2, page 13 - BGP Identifier - network byte order? 6142 > "IP address" -> "IPv4 address" 6144 I'll put at the beginning a sentence saying that in the context of 6145 this document the term "IP address" means an IP Version 4 address. 6147 > Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> 6148 > "path attributes" 6150 fixed. 6152 > Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address" 6153 > Specify that this is 4 octets. 6154 > Reference here to multi-protocol extensions for IPv6 6155 > nexthop? 6157 no. 6159 > RFC 2283 is unclear whether NEXT_HOP should always be 6160 > included when using multiprotocol extensions. Clarify 6161 > this here? 6163 It is already clarified in 2283bis. 6165 > Section 4.3, Page 17/18 - MED and LocalPref: 6166 > "non-negative" -> "unsigned" for consistency with 6167 > elsewhere. (non-negative might imply values > 2^31 6168 > cannot be used). 6170 fixed. 6172 > Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address" 6173 > Prefix: "enough trailing bits to" -> "the minimum number 6174 > of trailing bits needed to" 6176 fixed. 6178 > Section 4.4, Page 20: - "BGP does not use any TCP-based keep- 6179 alive 6180 > mechanism to determine if peers are reachable". Is it worth 6181 noting 6182 > that TCP may still timeout the connection even if TCP keepalives 6183 are 6184 > turned off? 6186 the text is fine as it is. 6188 > Section 4.4, Page 20: 6189 > KEEPALIVE message consists" -> "A KEEPALIVE message consists" 6191 fixed. 6193 > Section 5, Page 23: "The same attribute can not appear more than 6194 > once with the Path Attributes field...". Does this mean the same 6195 > attribute type, or the same attribute type and value? 6197 the former (the same attribute type). 6199 > Section 5.1 "The usage of each BGP path attributes .." -> 6200 > attribute 6202 fixed. 6204 > Section 5.1.3 "IP address" -> "IPv4 address" 6205 > 6206 > "A BGP speaker must never advertise an address of a peer to that 6207 > peer as a NEXT_HOP, for a route that the speaker is originating." 6208 > suggest replace this text with: 6209 > "A route originated by a BGP speaker must never be advertised to a 6210 > peer using an address of that peer as NEXT_HOP" 6212 fixed. 6214 > Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which 6215 > allows the MULTI_EXIT_DISC to be removed from a route." Might 6216 > want to say that this is dangerous unless you received the route 6217 > from an EBGP peer? 6219 think we should keep the text as is. 6221 > Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE 6222 > message that is received from an external peer, then this 6223 > attribute MUST be ignored by the receiving speaker, except for the 6224 > case of BGP Confederations [RFC3065]." 6225 > - "ignored" might be taken to mean that you don't process it for 6226 > decision, but that you propagate it to internal peers. I might 6227 > write "silently removed" or something similar. 6229 I think the text is ok as is. 6231 > Section 5.1.5, para 2. "set of AS" -> "set of ASs" 6233 fixed. 6235 > Section 6.3: wrt NEXT_HOP semantic correctness: should we check 6236 > that a NEXT_HOP is not a multicast or broadcast address? 6238 I'll add to the definition of NEXT_HOP that it is a unicast address. 6240 > Section 6.3, page 32, para 7: "peer than sent" -> "peer that 6241 > sent" 6242 fixed. 6244 > Section 6.3: "if any attribute appears more than once" - does this 6245 > mean the same attribute type, or the same attribute type and 6246 > value? 6248 the former. 6250 > Section 6.8 "Comparing BGP identifiers is done by treating them as 6251 > (4-octet-long) unsigned integers". Need to convert to host byte 6252 > order before comparing. 6254 fixed. 6256 > Section 6.8, item 2: "closes BGP connection" -> "closes the BGP 6257 > connection"; "accepts BGP connection" -> "accepts the BGP 6258 connection". 6260 fixed. 6262 > Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it 6263 > is unclear for IBGP connections how to determine "the neighbor AS 6264 > from which the other IBGP speaker learned the route". If this is 6265 > really the leftmost entry in the AS path (or the local AS if the 6266 > path is empty), the spec should explicitly say so. 6268 fixed. 6270 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6271 > attribute is removed before..." The first sentence is pretty 6272 > nearly incomprehensible. 6274 This topic has some more discussion surrounding what text we should 6275 use to clarify this issue. This is followed up in issue 18. 6277 > Section 9.1.2.2 (d) 6278 > "d) If at least one of the candidate routes was received from 6279 > an external peer in a neighboring autonomous system, remove 6280 > from consideration all routes which were received from 6281 > internal peers." 6282 > For consistency with (c) and clarity, this might be reworded: 6283 > "d) If any of the candidate routes was learned via EBGP, 6284 > remove from consideration all routes which were learned by 6285 > IBGP." 6287 fixed. 6289 > Section 9.1.2.2 (e) 6290 > "cost (n) is better than cost (m)" 6291 > Given the definition of cost, it might be clearer to say 6292 > "cost (n) is lower than cost (m)" 6294 fixed. 6296 > Section 9.1.2.2 (g) 6297 > "neighbor address" has not been defined. 6299 I'll replace "neighbor address" with "peer address". 6301 > Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes 6302 > of all routes to be aggregated should be ignored." 6303 > 6304 > Perhaps "ignored" is ambiguous here, and it's not clear 6305 > whether should is a SHOULD. Suggest: 6306 > 6307 > "Any AGGREGATOR attributes from the routes to be aggregated 6308 > MUST NOT be included in the aggregated route." 6310 fixed. 6312 > Section 9.3 - shouldn't this subsection be moved to the discussion 6313 > of Phase 1 or Phase 2 of the decision process? Or at least move 6314 it 6315 > before Section 9.2. 6317 I think it is fine where it is now. 6319 > Appendix E, para 2: IP precedence has been deprecated. Delete 6320 > this paragraph, or replace with appropriate diffserv codepoint. 6322 deleted. 6324 > Security Considerations: 6325 > "BGP supports the ability to authenticate BGP messages by using 6326 > BGP authentication." 6327 > This sentence should be removed, and the Authentication 6328 > Information parameter has been deprecated. 6330 Please see the recent e-mail exchange on the Security Considerations 6332 See issue 19 for more on the Security Considerations section of the 6333 draft. 6335 These topics were discussed in the "proxy: more comments on the draft 6336 -18" thread. 6338 3.17 Section 3, Page 8, Paragraph 3 - Obsolete? 6340 Status: Consensus 6341 Change: Yes 6342 Summary: Leave the current definition of BGP Speaker, and normalize 6343 the text to use "BGP Speaker" instead of router. 6345 Discussion: 6347 This issue was spawned from the discussions in issue 16, 6348 specifically: 6350 Anonymous reviewer: 6352 > Section 3, page 8, para 3 - "The hosts executing..." This 6353 > paragraph seems obsolete. 6355 Yakov: 6357 I'll take it out. 6359 With regard to this, Siva asked if some route optimization vendors 6360 rely on this. 6362 Jeff replied: 6364 To provide context, this paragraph currently reads: 6366 : The hosts executing BGP need not be routers. A non-routing host 6367 : could exchange routing information with routers via EGP [RFC904] 6368 : or even an interior routing protocol. That non-routing host could 6369 : then use BGP to exchange routing information with a border router 6370 : in another Autonomous System. The implications and applications 6371 of 6372 : this architecture are for further study. 6374 There are several deployed entities that could be considered to 6375 "exploit" this paragraph. Route collectors, route servers, 6376 bandwidth shapers and other optimizers. However, the original text 6377 may be showing its age a little bit. 6379 Perhaps the following might be a bit more appropriate: 6381 "The hosts executing BGP need not be routers. A non-routing host 6382 may 6383 exchange routing information with a BGP speaker for reasons 6384 that are outside the scope of this document." 6386 I would also propose adding to the same paragraph (but could be 6387 persuaded to drop it since it is *logically* redundant): "These non- 6388 routing hosts should exercise great care not to insert 6389 themselves into the forwarding path if they re-announce BGP 6390 routes." 6392 Yakov replied: 6394 Since operations of non-routing host are outside the scope of the 6395 document, and since the document doesn't preclude non-routing hosts 6396 to run BGP, I would prefer just to take the following paragraph out, 6397 and not to add any new text. 6399 The hosts executing BGP need not be routers. A non-routing host 6400 could exchange routing information with routers via EGP [RFC904] 6401 or even an interior routing protocol. That non-routing host could 6402 then use BGP to exchange routing information with a border router 6403 in another Autonomous System. The implications and applications of 6404 this architecture are for further study. 6406 Jeff replied that this was ok, and instead suggested: 6408 At the beginning of the document, we define: 6409 BGP speaker 6410 A router that implements BGP. 6412 This (potentially) restricts a speaker to being a router. 6413 Additionally, several spots in the text where we probably should 6414 say "BGP speaker", we use router. 6416 Yakov agreed to add this definition. 6418 Jeff replied that there still was a problem with this definition 6419 being too limiting. The discussion meandered off list for a couple 6420 of exchanges and these additional definitions were proposed: 6422 First Jeff proposed this: 6424 "A router that implements the BGP protocol. 6425 Non-routing hosts that also implement BGP are out of scope of this 6426 document." 6428 Then Andrew replied, that we should make sure the definition does not 6429 opt out entirely from making sure that non-routing hosts are 6430 interoperable: 6432 BGP Speaker 6433 A router that implements the BGP protocol. The internal behavior 6434 of non-routing hosts that also implement BGP are out of scope of 6435 this document. However, in their interactions with routers, non- 6436 routing hosts must behave as if they were routers. 6438 And Jeff replied: 6440 BGP Speaker 6441 A router that implements the BGP protocol. The internal behavior 6442 of non-routing hosts that also implement BGP are out of scope of 6443 this document. However, in their interactions with BGP speaking 6444 routers, non-routing hosts that implement BGP should be 6445 indistinguishable from a router on the wire. 6447 (or something like that - s/on the wire/ with whatever sounds best.) 6449 IOW, look like bgp on the wire - what you do internally is out of 6450 scope. 6452 Yakov replied, that we should keep the current definition, since it 6453 is clear that non-routing hosts are outside of the scope. Jeff 6454 responded that he is ok with that if we normalize the use of "BGP 6455 Speaker" instead of "BGP router" in the document. Yakov agreed to 6456 this, we are at consensus on this. 6458 This was discussed in the "proxy: more comments on draft -18" thread. 6459 And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - 6460 Obsolete?" thread. And also, the "issue 17 - final resolution" 6461 thread. 6463 3.18 MED Removal Text 6465 Status: Consensus 6466 Change: Yes 6467 Summary: Use text at the end of the discussion. 6469 Discussion: 6471 This issue is spawned from issue 16. 6473 An anonymous reviewer pointed out: 6475 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6476 > attribute is removed before..." The first sentence is pretty 6477 nearly > incomprehensible. 6479 Yakov replied: 6481 here is my attempt to clarify this: 6483 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6484 route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 6485 attribute may only be considered in the comparison of EBGP learned 6486 routes; the attribute is then removed, and then the remaining EBGP 6487 learned routes may be compared to the remaining IBGP learned 6488 routes, without considering the MULTI_EXIT_DISC attribute for those 6489 EBGP learned routes whose MULTI_EXIT_DISC attribute will be removed 6490 before advertising these routes to IBGP. 6492 Any further suggestions on how to improve this would be appreciated. 6494 Siva replied: 6496 How about this: 6498 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6499 route into IBGP, then comparison based on the MULT_EXIT_DISC 6500 attribute may (MUST?) be performed only among the EBGP learned 6501 routes. This comparison MUST be performed before the removal of 6502 the MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must 6503 then be removed from those EBGP routes where such removal is 6504 required and which are still eligible. This is followed by 6505 comparison with IBGP learned routes. 6507 I think this reflects our objectives, which is: 6509 a) If MED is to be removed, compare EBGP routes based on the MED 6511 b) Then remove the MED 6513 c) Then do comparison with IBGP routes 6515 Andrew suggested: 6517 If a router is configured to remove a MULTI_EXIT_DISC attribute from 6518 a route learned from EBGP, before re-advertising it into IBGP the 6519 router MUST compare the route with other EBGP-learned routes before 6520 removing the MULTI_EXIT_DISC. Once this comparison is complete, the 6521 MED may be removed, and any remaining routes can be compared with 6522 IBGP routes to determine the best route. 6524 Yakov replied: 6526 Here is the text that will go in the next version of the draft: 6528 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6529 route into IBGP, then comparison based on the MULT_EXIT_DISC 6530 attribute MAY be performed only among the EBGP learned routes. 6532 This comparison MUST be performed before the removal of the 6533 MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then 6534 removed from those EBGP routes where such removal is required and 6535 which are still eligible. This is followed by comparison with IBGP 6536 learned routes. 6538 Matthew responded to this with: 6540 I think this new text is ambiguous. 6542 >Here is the text that will go in the next version of the draft: 6543 > 6544 > If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6545 > route into IBGP, then comparison based on the MULT_EXIT_DISC 6546 > attribute MAY be performed only among the EBGP learned routes. 6548 This could be taken to mean either that the comparison may be 6549 performed, and if it's performed it must be performed only between 6550 EBGP learned routes, or that the comparison must be performed, but 6551 it may be performed only between EBGP learned routes. 6553 > This comparison MUST be performed before the removal of the 6554 > MULTI_EXIT_DISC attribute. 6556 If doing the comparison is optional, then I think that this sentence 6557 should read "If the comparison is performed, then it MUST be 6558 perfo..." 6560 > The MULT_EXIT_DISC attribute is then 6561 > removed from those EBGP routes where such removal is required and 6562 > which are still eligible. This is followed by comparison with 6563 > IBGP learned routes. 6565 6567 I think that it is desirable for an operator to be able to turn off 6568 MED processing entirely (including turning off all MED based 6569 comparisons), so I would suggest the following text: 6571 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6572 route into IBGP, comparison based on the received MULTI_EXIT_DISC 6573 attribute MAY be performed. If an implementation chooses to 6574 perform this comparison, then the comparison MUST be performed only 6575 among EBGP learned routes, and it MUST be performed before the 6576 removal of the MULTI_EXIT_DISC attribute. 6578 Curtis replied to Yakov's message: 6580 Looks good to me. 6582 I see no need to change "This comparison MUST be performed before 6583 the removal of the MULTI_EXIT_DISC attribute". There is no 6584 implication that MULTI_EXIT_DISC must be removed and the first 6585 sentence clearly indicates that doing so is not required therefore 6586 no ambiguity. Adding a "If a MULTI_EXIT_DISC attribute is removed" 6587 to the second sentence would be redundant. 6589 After some further discussion we have reached full consensus with: 6591 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6592 route into IBGP, then comparison based on the received EBGP 6593 MULTI_EXIT_DISC attribute MAY still be performed. If an 6594 implementation chooses to remove MULTI_EXIT_DISC, then the optional 6595 comparison on MULTI_EXIT_DISC if performed at all MUST be performed 6596 only among EBGP learned routes. The best EBGP learned route may 6597 then be compared with IBGP learned routes after the removal of the 6598 MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a 6599 subset of EBGP learned routes and the selected "best" EBGP learned 6600 route will not have MULTI_EXIT_DISC removed, then the 6601 MULTI_EXIT_DISC must be used in the comparison with IBGP learned 6602 routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used in 6603 route comparisons which reach this step in the decision process. 6605 This is discussed in the "proxy: more comments on draft 18" thread. 6606 And in the "issue 18" thread. 6608 3.19 Security Considerations 6610 Status: Consensus 6611 Change: Yes 6612 Summary: Fix Security Considerations section to include mandatory MD5 6613 auth 6614 and advance security considerations draft along with the base draft. 6616 Discussion: 6618 Yakov started this discussion by proposing text which would require 6619 TCP MD5 authentication for BGP implementations. This is to bring the 6620 spec in line with an IETF requirement that authentication be 6621 available. 6623 After some discussion the plan is to advance draft-ietf-idr-bgp- 6624 vuln-00.txt as Informational along with the base BGP specification. 6625 This draft will serve as the security analysis section of the base 6626 spec. 6628 This is discussed in the "revised Security Considerations section" 6629 thread. 6631 3.20 Peer Oscillation Damping 6633 Status: Consensus 6634 Change: No 6635 Summary: Keep the Peer Oscillation Damping reference in the 6636 specification. 6638 Discussion: 6640 This began when Siva proposed: 6642 Since this feature is going to be added in a new draft, and its 6643 addition will change the operation of the state machine, can we 6644 remove all mention of it in the state machine ? As part of this 6645 removal, can we also remove the IdleHold Timer from the FSM since it 6646 is not useful in the absence of peer oscillation damping ? 6648 The draft that describes this procedure can then describe the change 6649 in the state machine required to do this. 6651 Sue replied that: 6653 The reason we should not remove the peer oscillation damping 6654 from the state machine: 6656 1) Deployed implementations support peer oscillation damping 6657 2) Hooks for the additions in the FSM cannot be added later. 6659 These hooks are optional and do not need to be implemented. 6661 Siva replied: 6663 I understand. I am not trying to object to peer oscillation 6664 damping, I think it is a good idea and we have included it in 6665 our implementation as well. I was suggesting that instead of 6666 a partial description in this draft, it be completely described 6667 in the draft on peer oscillation damping. 6669 However, I do see your point, and unless there are any objections 6670 from others, I think we have consensus on this issue. 6672 This was discussed in the "Response to FSM input - Comments 1-10" 6673 thread: Comment #1. 6675 3.21 Session Attributes - IdleHold Timer 6676 Status: Consensus 6677 Change: Yes 6678 Summary: Add the text in the discussion section. 6680 Discussion: 6682 This discussion began with Siva asking: 6684 Why have a Hold Timer and a Hold Time ? Can we replace this with 6685 just Hold timer ? 6687 Can we also add the following session attributes: 6689 a) DelayBgpOpenTimer b) IdleHold Timer (in case we choose not to 6690 remove this from the base FSM) 6692 Can we also add the following flag to the session attributes: a) 6693 DelayOpen Flag 6695 After some discussion we have this text on the table: 6697 Event8: Idle hold timer expires 6699 Definition: An Event generated when the Idle Hold Timer 6700 expires. The Idle Hold Timer is only used 6701 when the persistent peer oscillation 6702 damping function is enabled. 6704 % Implementations not implemented persistent 6705 % peer oscillations damping functions may not 6706 % have the Idle Hold Timer. 6708 Sue replied: 6710 I will accept the new text for the following total text: 6712 Event8: Idle hold timer expires 6714 Definition: An event generated when the Idle Hold Timer 6715 expires indicating that the session has 6716 completed a back-off period to prevent bgp peer 6717 oscillation. 6719 The Idle Hold Timer is only used when the 6720 persistent peer oscillation damping function is 6721 enabled. 6723 Implementations not implementing the persistent 6724 peer oscillation damping functions may not have 6725 the Idle Hold Timer. 6727 Status: Optional 6729 We are at consensus with this. 6731 Tom added a couple of minor edits, correcting the spelling of 6732 "persistent" in the third paragraph, and pointing out that: 6734 oscillation damping functions may not have the Idle Hold ** function 6735 ** (because we only have function not functions in the previous 6736 sentence) Timer. 6738 Sue added the edits. 6740 Siva also liked the way this issue has turned out. 6742 This was discussed in the "Response to FSM input - Comments 1-10" 6743 thread: Comment #2. And in the "Draft 19 - issue #21" thread, 6744 alternately the "Draft 19 - Issue 21" thread. 6746 3.22 Specify New Attributes (Accept Connections/Peer Oscillation 6747 Damping) 6749 Status: Consensus 6750 Change: Yes 6751 Summary: Add the text in the discussion section to section 8.0. 6753 Discussion: 6755 This began with Siva proposing: 6757 Can we call these out as well: 6759 * Accept Connections from unconfigured peers (Enabled/Disabled) 6760 * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose 6761 not to remove it from base spec) 6763 After some discussion we have this text on the table: 6765 The following will be added to 8.0 6767 Optional parameters that may be supported either per 6768 connection or per implementation: 6770 1) Delay Open flag 6771 2) Delay Open Timer 6772 3) Perform automatic start flag 6773 4) Passive TCP establishment flag 6774 5) BGP stop_peer_flag flag 6775 6) Idle Hold timer 6776 7) Perform automatic stop flag 6777 8) Perform Collision detect in Establish mode flag 6779 Sue accepted these changes. 6781 Tom added this correction for item 2 in Sue's text: 6783 2) Delay Open Timer 6785 ** Open Delay timer 6786 ** (for which we have consensus in Issue list v2 item 7) 6788 Siva asked, and Sue accepted these additional changes: 6790 9) accept connections from un-configured peers 6791 5) BGP stop_peer_flap flag 6793 We are at consensus on this. 6795 This was discussed in the "Response to FSM input - Comments 1-10" 6796 thread: Comment #3. This was also discussed in the "BGP Draft 19 - 6797 Close open items 22" thread. 6799 3.23 Event1/Event2 Clean Up 6801 Status: Consensus 6802 Change: Yes 6803 Summary: Use "Local system administrator" in both sections. 6805 Discussion: 6807 Siva proposed that we clean up the text for these Events by selecting 6808 either "Administrator" or "Local system" but not both. 6810 Sue proposed text using "Local system administrator" that was agreed 6811 on. 6813 This was discussed in the "Response to FSM input - Comments 1-10" 6814 thread: Comment #4. 6816 3.24 Events 3, 5, 6 & 7 Give Examples 6818 Status: Consensus 6819 Change: No 6820 Summary: Leave the examples out. 6822 Discussion: 6824 This began with Siva proposing we add examples for these event 6825 states. Sue believes this is largely out-of-scope, but did agree to 6826 move the example of "automatic stop" to the event description 6827 section. She asked for proposed text for additional examples. 6829 Sue replied that she has made the following changes, and asked if 6830 these worked for Siva. 6832 New text: 6834 Event7: Automatic stop 6836 Definition: Local system automatically stops the 6837 BGP connection. 6839 An example of an automatic stop event is 6840 exceeding the number of prefixes for a given 6841 peer and the local system automatically 6842 disconnecting the peer. 6844 Status: Optional depending on local system 6846 Siva thought this for Event 7 was fine. 6848 Sue replied to the list, saying that, previously examples had caused 6849 dissension, and asked if there was a strong feeling either way. 6851 Siva proposed this text for Events 3, 5 & 6: 6853 Event 3: 6854 Examples of this event are: 6855 When a connection is terminated during exchange of Open 6856 messages due to version failure 6858 Event 5: 6859 Examples of this event are: 6860 Similar to Event 3 6862 Event 6: 6863 Examples of this event are: 6864 Similar to Event 3 and 6865 b) When a Idle Hold timer expires (within local limit) 6867 Sue replied to this: 6869 I'm going to leave the examples out of events 3, 4, 6 since 6870 I've not heard any strong input on the mail list **and** 6871 I had strong comments on prior versions of the draft. 6873 I'd like to declare that issue 24 has consensus. 6875 Siva agreed, we are at consensus on this issue. 6877 This was discussed in the "Response to FSM input - Comments 1-10" 6878 thread: Comment #5. This was also in the "Issue 25" thread, and the 6879 "Issue 25 - this is really issue 24" threads. This is also in the 6880 "Draft 19 - Issue 24" thread. 6882 3.25 Event 4 & 5 Session Initiation Text 6884 Status: Consensus 6885 Change: No 6886 Summary: Leave the text as is. 6888 Discussion: 6890 This began with Siva wanting to change: 6892 Definition: Local system automatically starts the 6893 BGP session with the passive flag enabled. The 6894 passive flag indicates that the peer will listen prior to 6895 establishing a connection. 6897 to: 6899 The passive flag indicates that the state machine will wait for 6900 specified peer to initiate a connection with the local system. If 6901 this does not happen within a specific time (hold time), the local 6902 system will then also attempt to initiate connection with the 6903 specified peer. 6905 Sue replied: 6907 The text in 8.2.1.1 indicates the definition of the passive flag. 6909 6a) 6910 ========== 6911 My understanding of your text is that you want to replace in both 6912 sets of text: 6914 "The passive flag indicates the peer will listen prior to 6915 establishing a connection". 6917 with: 6919 "The passive flag indicates that the state machine will wait for the 6920 specified peer to initiate a connection with a local system. 6922 The problem with this sentence is that in the "unconfigured" case 6923 the phrase "specified" peer is confusing. I think the original text 6924 is clearer. 6926 6b) 6927 ========== 6928 If this does not happen within a specific time (hold time), the 6929 local system will then also attempt to initiate (a) connection 6930 with the specified peer. 6932 My comments: Again, the "specified peer" term is confusing. Also, 6933 the 2nd half of the statement mixes the actions of the state machine 6934 with the events. I believe this muddies the text instead of 6935 clarifying it. 6937 Siva and Sue later agreed to leave the text the same because of the 6938 Unconfigured + passive TCP connection + Delay Open situation. 6940 This was discussed in the "Response to FSM input - Comments 1-10" 6941 thread: Comment #6. 6943 3.26 Event 4 & 5 - bgp_stop_flap option 6945 Status: Consensus 6946 Change: Yes 6947 Summary: Add new event below. 6949 Discussion: 6951 This began with Siva asking: 6953 Won't a variant of this with bgp_stop_flap option set be required ? 6954 We can also achieve the same by using the bgp_stop-Flap option as a 6955 flag that is provided as an input to the state machine. 6957 Siva later clarified this to include: 6959 We already have 6960 Event 3 - Automatic Start 6961 Event 5 - Automatic start with bgp_stop_flap option set 6962 To make things consistent, shouldn't we either 6963 a) Add 3 new events : 6964 1) Manual start with bgp_stop flap option set 2) 6965 Manual start with passive TCP establishment and 6966 bgp_stop_flap option set 3) Automatic start with 6967 passive TCP establishment and bgp_stop_flap 6968 option set 6970 or 6972 b) Remove Event 6, and rely on a flag to tell us wither peer flap 6973 damping is to be performed for the session or not. 6975 Sue said she preferred option A. And stated that #1 & #2 are 6976 infeasible, but that we need to add #3. 6978 Tom replied: 6980 But if we add an event, then we must add and agree on actions for 6981 all six existing states so I think to say that adding a new event 6982 settle things might be naive. 6984 If we do add 6985 3) Automatic start with passive TCP establishment and bgp_stop_flap 6986 option set 6988 which I understand is Sue's resolution, then for Idle state the 6989 actions are straightforward but for the other five, is the event 6990 completely ignored? If so, does it mean that the passive flag and 6991 the bgp_stop_flap option are ignored and we carry on as if we were 6992 when we were started which may have been without them. Or is the 6993 fact of starting ignored but the flags remain set and so color the 6994 effect of other events? Needs defining. 6996 Jeff replied to this, quoting the existing draft: 6998 The start events [Event 1, 3-6] are ignored in connect 6999 state. 7001 The start events [Event1, 3-6] are ignored in the Active 7002 state. 7004 The Start events [Event1, 3-6] are ignored in the OpenSent 7005 state. 7007 Any start event [Event1, 3-6] is ignored in the OpenConfirm 7008 state. 7010 Any start event (Event 1, 3-6) is ignored in the 7011 Established state. 7013 And elaborated, saying that: 7015 "ignore" means do nothing. This means don't twiddle with the flags. 7016 :-) 7018 The text that was finally agreed on is: 7020 Event 7: Automatic start with bgp_stop flap option set and 7021 passive TCP establishment option set 7023 Definition: Local system automatically starts the 7024 BGP peer connection with peer oscillation 7025 damping enabled and passive TCP establishment 7026 enabled. The exact method of damping persistent 7027 peer oscillations is left up to the 7028 implementation, and is outside the scope of this 7029 document. 7031 Status: Optional, used only if the bgp peer has 7032 enabled bgp peer oscillation damping with 7033 following optional flags settings below. 7035 Optional 7036 attributes: 1) Perform automatic start flag SHOULD be set 7037 2) BGP stop_peer_flap flag SHOULD be set 7039 I've re-ordered the Timer events to keep the text changes 7040 down to a minimum. 7042 action 9 - connect retry timer 7043 action 10 - Hold Timer expires 7044 action 11 - Keepalive timer expires 7045 action 13 - Open Delay timer expires 7046 action 14 - Idle Hold timer expires 7048 All other events are incremented by 1 7050 This was discussed in the "Response to FSM input - Comments 1-10" 7051 thread: Comment #7. 7053 3.27 Event 5 Clarification 7055 Status: Consensus 7056 Change: No 7057 Summary: Leave the text as is. 7059 Discussion: 7061 This began when Siva asked that in event 5: 7063 Is it correct that this event will occur only when we want to 7064 restart a connection (after it had been terminated due to some 7065 reason beside administrative action) that we had accepted from an 7066 unconfigured peer ? 7068 Sue replied: 7070 The automatic start function is an implementation specific 7071 mechanism. This text does not seek to restrict it in any fashion. 7073 Siva said that although he felt his original clarification would be 7074 more useful to new implementors he is ok with the text as is. 7076 This was discussed in the "Response to FSM input - Comments 1-10" 7077 thread: Comment #8. 7079 3.28 Timer Events Definition - Make Consistent 7081 Status: Consensus 7082 Change: Yes 7083 Summary: Change text to use "generate" across the board. 7085 Discussion: 7087 Can we use similar language for Events 8-12 to make them consistent? 7089 It was agreed that we will use "generate" i.e.: 7091 Event 8: An event generated when the Idle Hold timer expires. 7092 Event 9: An event generated when the ConnectRetry timer expires. 7093 Event 10: An event generated when the Hold timer expires. 7094 Event 11: An event generated when the Keepalive timer expires 7095 Event 12: An event generated when the Delay BGP Open timer expires. 7097 This is at consensus. 7099 This was discussed in the "Response to FSM input - Comments 1-10" 7100 thread Comment #9. 7102 3.29 Event 8 - Clean Up 7104 Status: Consensus 7105 Change: Yes 7106 Summary: Clean up first sentence. New text below. 7108 Discussion: 7110 Siva began this by asking if we could clean up the wording of Event 7111 8. 7113 After some discussion with Sue we are at this change for the first 7114 sentence: 7116 An event triggered by the expiry of the Idle Hold timer, indicating 7117 that the session has completed waiting for a back-off period to 7118 prevent bgp peer oscillation. 7120 This was discussed in the "Response to FSM input - Comments 1-10" 7121 thread: Comment #10. 7123 3.30 Hold Timer - Split? 7125 Status: Consensus 7126 Change: No 7127 Summary: Keep the hold timer text as is. 7129 Discussion: 7131 Siva proposed that since: 7133 We use the hold timer for two purposes 7135 * Waiting for an open message (with a default value of 240 seconds) 7136 * Waiting for Keepalives (with a default value of 90 seconds) 7138 Can we use two different timers (or at least call them two different 7139 timer events) ? 7141 Sue replied that this is not how it is implemented currently. Siva 7142 replied that we have two conceptually different timers, but that it 7143 would certainly work to only have one, since only one needs to be 7144 running at any given time. 7146 Tom agreed that we can keep things as is. 7148 This was discussed in the "Comments 11-20" thread: Comment #11. 7150 3.31 OpenDelay Timer Definition 7152 Status: Consensus 7153 Change: Yes - See issue 28 7154 Summary: This is fixed by the fixing of issue 28. 7156 Discussion: 7158 This began with Siva's request that we add something to Event 12 to 7159 specify what to do when the timer expires. This seems to have been 7160 addressed in issue 28. 7162 This was discussed in the "Comments 11-20" thread: Comment #12. 7164 3.32 Definition of TCP Connection Accept (Event 13) 7166 Status: Consensus 7167 Change: Yes 7168 Summary: Change "Definition" text as indicated below. 7170 Discussion: 7172 Siva proposed that we change text from referring to "TCP connection 7173 request" to "receiving a TCP connection". This led to this proposed 7174 text: 7176 Definition: Event indicating the reception of a TCP 7177 connection 7178 request with a valid source IP address and TCP 7179 port, and valid destination IP address and 7180 TCP Port. The definition of invalid source 7181 address and port and invalid destination address 7182 is left to the implementation. 7184 This met with agreement. 7186 This thread also discussed the idea of filtering the incoming 7187 address/port. It was decided that this was implementation dependent. 7189 This was discussed in the "Comments 11-20" thread: Comment #13. 7191 3.33 Event 13 & 14 - Valid Addresses & Ports 7193 Status: Consensus 7194 Change: Yes 7195 Summary: See text at the end of the discussion. 7197 Discussion: 7199 With regard to Event 13 & 14, Siva raised questions about: 1) What 7200 does it mean to validate a port, and 2) Should we state what we 7201 consider an invalid IP address to be? 7203 Sue replied that this is local policy and is implementation 7204 dependent. Siva agreed regarding the source port & IP address, but 7205 disagreed about the destination port. He argued that we need to know 7206 the destination port for interoperability. 7208 Sue asked Siva to provide some text. 7210 After a long lull, Sue replied with: 7212 I would like to keep the current text of 7213 "Should" in the following text 7215 "BGP's destination port SHOULD be port 179 7216 as defined by IANA." 7218 Should indicates that it normally should 7219 be 179. If an implementation allows for 7220 an alternative TCP port, it is still valid as the 7221 "MUST" is not indicated. 7223 There have been no further comments on this, the chairs have decided 7224 to close it. 7226 This was discussed in the "Comments 11-20" thread: Comment #14. This 7227 was also in the "BGP-19: Issue 33" thread. 7229 3.34 Event 17 - TCP Connection Fails to TCP Connection Termination 7231 Status: Consensus 7232 Change: Yes 7233 Summary: Change the text to "fails." 7235 Discussion: 7237 This began with Siva observing: 7239 This event can occur even when the transport connection is closed by 7240 the other end. Since this does not reflect a 'failure ', can we 7241 change the event name to 7243 % Event17: TCP connection termination 7245 Sue replied that: 7247 Discussion: It both terminates from the remote site 7248 and can "timeout" - fail. 7250 Suggestions? I can use "disconnect", what do you think. 7252 Siva replied that this was a minor issue, and on further reflection, 7253 either "fails" or "disconnect" would be acceptable. 7255 Sue replied that she has accepted Siva's comments, and the text will 7256 be changed to "fails". 7258 This was discussed in the "Comments 11-20" thread: Comment #15. This 7259 was also discussed in the "BGP-19: Issue 34-35, 40-48" thread. 7261 3.35 Making Definition Style Consistent 7263 Status: Consensus 7264 Change: Yes 7265 Summary: Adopt consistent style for the definition of events. 7267 Discussion: 7269 This started with Siva asking if we could make the definition style 7270 consistent across events. Sue replied to this with text for 13-17, 7271 Siva clarified that he was talking more about 18-21, and proposed 7272 text. 7274 We are agreed on the text for 13-17: 7276 Event13: TCP connection indication and valid remote peer 7278 Definition: Event indicating the local system reception 7279 of a TCP connection request with a valid source 7280 IP address and TCP port, and valid destination 7281 IP address and TCP Port. The definition of 7282 invalid source, and invalid destination IP 7283 address is left to the implementation. 7285 BGP's destination port SHOULD be port 179 as 7286 defined by IANA. 7288 TCP connection request is denoted by the local 7289 system receiving a TCP SYN. 7291 Status: Mandatory (Optional) 7293 Event14: RCV TCP connection indication with invalid source or 7294 destination 7296 Definition: Event indicating the local system reception 7297 of a TCP connection request with either 7298 an invalid source address or port 7299 number or an invalid destination 7300 address or port number. 7302 BGP destination port number SHOULD be 179 7303 as defined by IANA. 7305 Again, a TCP connection request 7306 denoted by local system receiving a TCP 7307 SYN. 7309 Status: Mandatory (Optional) 7311 Event15: TCP connection request sent received an ACK. 7313 Definition: Event indicating the Local system's request 7314 to establish a TCP connection to the remote 7315 peer. 7317 The local system's TCP session sent a TCP 7318 SYN, and received a TCP SYN, ACK pair of 7319 messages, and Sent a TCP ACK. 7321 Status: Mandatory 7323 Event16: TCP connection confirmed 7325 Definition: Event indicates that the local system 7326 receiving a confirmation that the TCP 7327 connection has been established by the 7328 remote site. 7330 The remote peer's TCP engine sent a TCP SYN. 7331 The local peer's TCP engine sent a SYN, ACK 7332 pair, and now has received a final ACK. 7334 Status: Mandatory 7336 Event17: TCP connection fails 7338 Definition: Event indicates that the local system has 7339 received a TCP connection failure notice. 7341 The remote BGP peer's TCP machine could have 7342 sent a FIN. The local peer would respond 7343 with a FIN-ACK. Another alternative is that 7344 the local peer indicated a timeout in the 7345 TCP session and downed the connection. 7347 Status: Mandatory 7349 Siva proposed these changes for 18-21: 7351 Event18: BGPOpen 7353 Definition: An event indicating that a valid Open 7354 message has been received. 7356 with 7358 Event18: BGPOpen 7360 Definition: An event is generated when a valid Open 7361 message has been received. 7363 Event19: BGPOpen with BGP Delay Open Timer running 7365 Definition: An event indicating that a valid Open 7366 message has been successful 7367 established for a peer that is 7368 currently delaying the sending of an 7369 BGP Open message. 7371 with 7373 Event19: BGPOpen with BGP Open Delay Timer running 7375 Definition: An event is generated when a valid Open 7376 message has been received for a peer that 7377 is currently delaying the sending of a 7378 BGP Open message. 7380 Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer" 7381 per issue 7. 7383 Event20: BGPHeaderErr 7385 Definition: BGP message header is not valid. 7387 with 7389 Event20: BGPHeaderErr 7391 Definition: An event is generated when a received BGP 7392 message header is not valid. 7394 Event21: BGPOpenMsgErr 7395 Definition: An BGP Open message has been received 7396 with errors. 7398 with 7400 Event21: BGPOpenMsgErr 7402 Definition: An event is generated when BGP Open message 7403 with errors has been received. 7405 Sue replied that she accepted Siva's comments, so we are at consensus 7406 here. 7408 This was discussed in the "Comments 11-20" thread: Comment #16. This 7409 also came up in the "BGP-19: Issue 34-35, 40-48" thread. 7411 3.36 Event 19 - Definition Cleanup 7413 Status: Consensus 7414 Change: Yes 7415 Summary: Replace definition for Event 19 with the text in the 7416 discussion. 7418 Discussion: 7420 Siva proposed we replace: 7422 Definition: An event indicating that a valid Open Message has been 7423 successful established for a peer that is currently delaying the 7424 sending of an BGP Open message. 7426 with: 7428 Definition: An event indicating that a valid OPEN Message has been 7429 received for a peer that has a successfully established transport 7430 connection and is currently delaying the sending of a BGP open 7431 message 7433 in Event 19. Sue agreed to the changes. 7435 This was discussed in the "Comments 11-20" thread: Comment #17. 7437 3.37 Event 22 - Cleanup 7439 Status: Consensus 7440 Change: Yes 7441 Summary: Replace Event 22 definition with the text from the 7442 discussion. 7444 Discussion: 7446 Siva began with observing: 7448 Event22: Open collision discard 7450 Definition: An event generated administratively 7451 when a connection Collision has been 7452 detected while processing an incoming 7453 Open message. This connection has been 7455 Isn't this event 'automatically' generated, since it is a system 7456 generated event ? 7458 Sue replied that: 7460 response: How this generated is implementation specific. The 7461 "administratively" is to cover policy. 7463 Siva also proposed an editorial fix with: 7465 Event 22 is an administrative could 7466 occur if FSM is implemented as two 7468 The word event is missing. How about 7470 Event 22 is an automatic event that 7471 could occur if FSM is implemented as two 7473 Sue replied with this rewritten text: 7475 Event22: Open collision dump 7477 Definition: An event generated administratively 7478 when a connection collision has been 7479 detected while processing an incoming 7480 OPEN message and this connection has been 7481 selected to disconnected. See Section 7482 6.8 for more information on collision 7483 detection. 7485 Event22 is an administrative based only 7486 implementation specific policy. This 7487 Event may occur if the FSM is implemented 7488 as two linked state machines. 7490 Siva agreed with this new text. 7492 This was discussed in the "Comments 11-20" thread: Comment #18. 7494 3.38 FSM Description - ConnectRetry Count 7496 Status: Consensus 7497 Change: No 7498 Summary: Leave the counter text alone, since it is used in peer 7499 oscillation and will be in the MIB. 7501 Discussion: 7503 Siva opened with this question: 7505 The Connect Retry count is updated by the FSM but never used. In the 7506 absence of peer oscillation damping, will this be used to stop 7507 connection establishment attempts after a certain maximum number ? 7509 7510 Yes, this is either implementation specific or 7511 is it based on the peer oscillation damping draft. 7513 Can we include the use of this counter in some place ? 7515 7516 Connect retry counter 7517 1) Will be utilized by the peer oscillation damping 7518 draft. 7519 2) Will be included in bgp-4-mibv2-xx. 7520 I just check and I didn't find it. 7522 Do you still want text in the main? 7524 To which Siva replied that he believes we can leave the main text 7525 alone. 7527 This was discussed in the "Comments 11-20" thread: Comment #19. 7529 3.39 Handling Event 7 (Auto Stop) to Idle State processing 7531 Status: Consensus 7532 Change: Yes 7533 Summary: Fix the text as indicated in the discussion. 7535 Discussion: 7537 Siva began with: 7539 The handling of Event 7 is missing from the Idle State processing. 7540 Can we add this ? How about replacing 7542 An manual stop event (Event2) is ignored in the Idle state. 7544 with 7546 Manual stop (Event 2) and Auto stop (Event 7) events are ignored 7547 in the Idle state 7549 Sue replied that she would add the text. 7551 This was discussed in the "Comments 11-20" thread: Comment #20. 7553 3.40 Clearing the Connection Retry Timer 7555 Status: Consensus 7556 Change: No 7557 Summary: Leave things alone, since it is better to be redundant than 7558 to let something slip through. 7560 Discussion: 7562 Siva opened with the observation: 7564 There are a few sections where the FSM draft states that the 7565 Connection Retry timer needs to be reset, whereas the connect retry 7566 timer had been cleared prior to entering that state. We can remove 7567 these instructions to clear the connect retry timer. 7569 List of places where the connect retry timer need not be cleared 7571 a) Handling of Event 19 in the Connect State 7572 b) Handling of Events 12 in the Active State 7573 c) All cases where it is referred to in the OpenSent, 7574 OpenConfirm and Established states 7576 Sue replied: 7578 Comment: 7579 1) Does it hurt to have the connect retry timer cleared 7580 at these points, since it has already been cleared. 7582 I felt it eased the implementations to allow the action 7583 routines to be shared across as many states as possible. 7584 You can see this a bit more actively. 7586 Tom replied to this: 7588 I propose we leave it in and close this issue. 7590 1) To take out an action as redundant you need to be supremely 7591 confident that it really cannot make a difference. I am not 7592 (supremely confident); rather, the more I look at the FSM, the more 7593 places I find where actions are missing, as I have posted to the 7594 list, from obscure yet possible sequences of events and timing. And 7595 there is an outstanding issue of mine which flagged seven places 7596 where the next state was missing and so I think it impossible for 7597 any one to be confident that any particular action is redundant 7598 until that is cleared up and that is proving complex in some cases. 7599 So, play safe, keep them in. 7601 2) The argument for removing them is that the number of possible 7602 distinct action lists is increased. True - it will mean that an 7603 implementor will have to code more code when first implementing BGP. 7605 For me this is no contest; keeping it safe at the possible cost of 7606 redundancy outweighs the one-off cost of additional implementation. 7608 So keep the actions in and close the issue. 7610 Jeff replied that he agreed with Tom on this. 7612 Siva concurred, that this approach was acceptable. 7614 Unless someone objects, this issue is at consensus. 7616 This was discussed in the "Comments 21-30" thread: Comment #21. This 7617 is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry 7618 timer" thread. 7620 3.41 Handling of Event 14 in the Connect State 7622 Status: Consensus 7623 Change: Yes 7624 Summary: Make event 14 optional. 7626 Discussion: 7628 Siva opened the discussion with: 7630 > If the transport connection receives an indication 7631 > that is invalid or unconfigured. [Event 14]: 7632 > - the TCP connection is rejected. 7634 I don't understand how we would get this event while in this state. 7636 Sue replied: 7638 See my earlier comments (1-10) on the connection state. 7639 It happens in implementations which track the TCP state more 7640 closely. I suggest that Event 14 become optional. 7642 Sue also suggested we fold this into the discussion about events 7643 13-17, which is tracked in issue 13.4. 7645 Sue proposed: 7647 My resolution: Let event 14 be optional. 7648 Not all BGP implementations support it. 7650 And asked if this let us reach consensus on this issue. 7652 Siva agreed with this, we are at consensus on this. 7654 This was discussed in the "Comments 21-30" thread: Comment #22. This 7655 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7657 3.42 Handling events 20, 21 in the Connect State and Active State 7659 Status: Consensus 7660 Change: Yes 7661 Summary: Use the text Tom proposed in the discussion section. 7663 Discussion: 7665 Siva began this with: 7667 We need to consider the case where we receive events 20 (message 7668 header error) and 21 (Open message error) when the delay timer is 7669 running. 7671 Since the connection has been established at this point, we need to 7672 send a Notification message and then terminate the connection. 7674 To which Sue replied: 7676 Alternative comments: 7678 1) We have not sent an Open statement. 7679 2) Why do we have to send an Notification? I see no justification 7680 for it. 7682 Suggestion: 7683 Do you have implementations that send notification? Do 7684 you know of others that don't. 7686 Jeff saw this as indicative of an issue with section 4.2 the way it 7687 is currently written: 7689 >From section 4.2 of -18: 7690 4.2 OPEN Message Format 7692 After a TCP is established, the first message sent by each side 7693 is an OPEN message. If the OPEN message is acceptable, a 7694 KEEPALIVE message confirming the OPEN is sent back. Once the OPEN 7695 is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be 7696 exchanged. 7698 This text implies that NOTIFICATIONs can only be sent once we 7699 have sent an open and then a keepalive, generally meaning we're 7700 in the Established state. 7702 Anyone suggestions for modifying the wording? 7704 Section 6.1 (Message header error) is one situation that implies 7705 that a NOTIFICATION can be sent without sending even an OPEN 7706 message. Note that since the base FSM implies that we send an 7707 OPEN message immediately when we have a completed transport 7708 connection, we SHOULD be in at least OpenSent. However, the 7709 DelayOpen timer means that we MAY send a NOTIFICATION when we are 7710 in the Connect state. 7712 GateD, at least, will not send a NOTIFICATION without first 7713 sending an OPEN. 7715 We need to pick one: You can send NOTIFICATIONS before OPEN or 7716 before OPEN if the OpenDelay timer is running. However, we MUST 7717 fix the text above. 7719 Tom opined: 7721 A NOTIFICATION without a preceding OPEN is rather hard to interpret; 7722 it is the OPEN that gives the recipient what it needs to know about 7723 its potential peer (Version, AS number, ID, options etc) so it makes 7724 sense to send an OPEN even if it is followed by a NOTIFICATION to 7725 say goodbye :-( as opposed to a KEEPALIVE which says hello:-). 7727 But as ever, what is implemented? 7729 Yakov suggested these modifications to the text to resolve this: 7731 1. Delete the last sentence in the above paragraph 7732 or 7734 2. Delete "and NOTIFICATION" in the last sentence in the above 7735 paragraph 7737 Jeff replied that he preferred the first option, and that the second 7738 could be interpreted as NOTIFICATIONs not being legal, when, in fact, 7739 they may. 7741 So the text on the table to resolve this is: 7743 4.2 OPEN Message Format 7745 After a TCP is established, the first message sent by each side 7746 is an OPEN message. If the OPEN message is acceptable, a 7747 KEEPALIVE message confirming the OPEN is sent back. 7749 However, this does not entirely clear up the original point about the 7750 FSM. If we receive an error in Connect/Active, do we send a NOTIFY? 7751 Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in 7752 immediate succession? 7754 Sue replied: 7756 I suggest we don't send a "NOTIFICATION" when Event 20 or Event 21 7757 is received in Connect or Active state. 7759 Tom responded to this issue with: 7761 Issue 42 queries whether or not we can send a NOTIFICATION when we 7762 have not successfully exchanged OPENs. I propose we should, 7763 following the suggestions of Jeff and Yakov. 7765 As Yakov suggested, this requires the removal of the second 7766 sentence, first paragraph, of 4.2 which implies a NOTIFICATION can 7767 only be sent after a successful exchange of OPENs. I think this 7768 fits best with the other references to the uses of NOTIFICATION in 7769 the draft. 7771 In terms of the FSM, it means that in Connect and Active states, on 7772 receipt of events 20 or 21, we should send a NOTIFICATION so that 7773 the last section starting 7775 In response to any other event............. 7777 is replaced by (and noting we have agreed to drop references to MIB 7778 actions) 7779 If the BGP message header checking or OPEN message 7780 checking detect an error (see Section 6.2) [Events 20 or 21], 7781 the local system: 7782 - sends a NOTIFICATION message with the appropriate 7783 error code, 7784 - resets the connect retry timer (sets to zero), 7785 - releases all BGP resources, 7786 - drops the TCP connection 7787 - increments the ConnectRetryCnt (connect retry count) 7788 by 1, 7789 - [optionally] performs peer oscillation damping 7790 - and goes to the Idle state. 7792 In response to any other event (Events 7-8, 10-11,18, 22-27), the 7793 local system: 7794 - resets the connect retry timer (sets to zero), 7795 - releases all BGP resources, 7796 - drops the TCP connection, 7797 - increments the ConnectRetryCnt (connect retry count) 7798 by one, 7799 - [optionally] performs peer oscillation damping, 7800 - and goes to the Idle state 7802 (Note that this text is not quite watertight. Suppose we are in 7803 Active state, having been started with CRT running, receive an SYN 7804 (event 13), send SYN-ACK and then get a malformed message (events 7805 20/21). We have not yet received an ACK and so should not send 7806 anything over TCP; I would expect TCP to buffer this awaiting the 7807 ACK except we then take down the TCP connection - or try to; I don't 7808 know what happens next but regard it as sufficiently obscure not to 7809 be concerned). 7811 (My other concern is greater; why do we now not send NOTIFICATIONs 7812 for other events; in Open Sent, Open Confirm or Established, we send 7813 one for the 'default event list' so what makes events 20 and 21 in 7814 Active and Connect so special? I can justify the absence of a 7815 NOTIFICATION for events 7, 8, 10, 11, 18, 22 since there is no 7816 evidence of a TCP connection to send it on; but events 23-27 in 7817 Active or Connect say we have received an erroneous message, the TCP 7818 connection is there so why not send a NOTIFICATION? 7819 Event7: Automatic stop 7820 Event8: Idle hold timer expires 7821 Event10: Hold timer expires 7822 Event11: Keepalive timer expires 7823 Event18: BGPOpen 7824 Event22: Open collision dump 7825 Event23: NotifMsgVerErr 7826 Event24: NotifMsg 7827 Event25: KeepAliveMsg 7828 Event26: UpdateMsg 7829 Event27: UpdateMsgErr 7831 Sue accepted Tom's text, so barring any objections, we are at 7832 consensus on this. 7834 This was discussed in the "Comments 21-30" thread: Comment #23. This 7835 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and 7836 the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread. 7838 3.43 Handling the default events in the Connect state 7840 Status: No Consensus 7841 Change: Potentially 7842 Summary: Add text at the end of the discussion. 7844 Discussion: 7846 Siva opened this with: 7848 The Open Delay timer [original: BGP Delay Open Timers) needs to be 7849 cleared if it is running. 7851 How about adding this: 7853 % - If the ConnectRetry Timer is running 7854 % - Clear the Connect Retry timer 7855 % - Otherwise 7856 % - Clear the Open Delay timer [original: BGP Delay Open Timer] 7858 Sue replied that: 7860 By the default you mean the text: 7862 In response to any other events[Events 7-8, 10-11, 18, 7863 20-27], the local system: 7865 "resets" to me implies stops and clears. I think the 7866 text is clear than the text above. 7867 ------------ 7868 Is this the replacement text you imply above: 7869 - resets the connect retry timer (sets to zero), 7870 - clears the Open Delay timer [original: BGP Delay timer] (sets to 7871 zero), 7872 - increments the ConnectRetryCnt (connect retry count) by 1, 7873 - [optionally] performs bgp peer oscillation damping, and 7874 - goes to Idle text: 7876 Editor's note: various incarnations of "Open Delay timer" have been 7877 replaced with "Open Delay timer". See issue 7. 7879 Sue replied that she accepted Siva's changes with these editorial 7880 changes: 7882 old text: 7883 - resets the connect retry timer (sets to zero) 7884 - clears the open delay timer 7886 new text: 7887 - if the connect retry timer is running, 7888 clear the connect retry timer (set to zero). 7889 - if the open delay timer is running, 7890 clear the open delay timer (set to zero). 7892 Since the substantive changes have been accepted, unless someone 7893 objects, this issue is at consensus. 7895 This was discussed in the "Comments 21-30" thread: Comment #24. This 7896 was also brought up in the "BGP-19: Issue 34-35, 40-48" 7898 3.44 Handling Event 23 in Connect and OpenSent 7900 Status: Consensus 7901 Change: Yes 7902 Summary: Adopt text at the end of the discussion section. 7904 Discussion: 7906 This began with Siva saying: 7908 This is currently being handled in the default event processing 7909 section. However, we do not need to go through the peer oscillation 7910 damping process in this case. Can we change the wordings to reflect 7911 this, or move this out of peer oscillation damping processing ? 7913 Sue replied: 7915 1) There is no default event handling process in the text, you 7916 will need to specify the text. 7918 2) The state table below (hares-statemt-03.txt) states shows 7919 the changes 7921 ------------- 7922 Event 23 7923 states: 7925 current Idle Connect Active Open-Sent Open-Cnf Establish 7926 ------------------------------------------------- 7927 next state Idle Idle Idle Idle Idle Idle 7928 ------------------------------------------------- 7929 action V D D Y Y T 7930 ================================================= 7932 V - Indicate FSM errors and ignore. D - 1) resets the connect retry 7933 timer (sets to zero), 7934 2) drops the TCP connection, 7935 2) releases all BGP resources, 7936 3) increments the ConnectRetryCnt (connect retry count) by 1, 7937 4) [optionally] performs the bgp peer oscillation damping, and 7938 Goes to Idle state. 7940 Y 1) resets the connect retry timer (sets to zero), 7941 2) Drops the TCP connection, 7942 3) releases all BGP resources, 7943 4) [optionally] 7945 In an exchange between Siva and Sue, this came up: 7947 Siva: 7949 "Default event handling" was perhaps a poor choice of words. 7951 What I meant is this 7953 Event 23 (Notify Message Version error) only indicates a version 7954 mismatch. By going through action sequence D, we will be performing 7955 peer oscillation damping. Should we perform damping, since this is 7956 not really a cause for persistent oscillation ? 7958 Also, since we have a distinct event to indicate a version error 7959 event, can include text indicating that version negotiation 7960 processing should take place upon receipt of this event ? 7962 Sue: 7964 Yes, we can change the "D" in state machine to a "y". 7966 The issue is what if Connect state occurs and there is not 7967 a TCP connection. Should an OPEN with wrong version 7968 be accepted? If the Open Delay flag is off, the connection 7969 state should not be getting an Open. The "D" action below 7970 works for "open delay flag off". 7972 The "y" action you suggest can occur if the open delay 7973 timer is on. 7975 If this is the issue, please confirm. 7977 We could say: if open delay flag is on -> y action 7978 if open delay flag is off -> D action 7980 Please let me know if this is the concern, and suggest 7981 text. 7983 Prior to this exchange, this issue was at consensus. The only thing 7984 that is firm in this exchange is changing "D" to "y". There seems to 7985 be some open discussion still, so we'll reopen it. 7987 After some discussion, this is the text we have settled on: 7989 If a NOTIFICATION message is received with a version 7990 error[Event24], the local system checks the Open Delay timer. 7991 If the Open Delay timer is running, the local system: 7992 - resets the connect retry timer (sets to zero), 7993 - stops and reset the Open Delay timer (sets to zero, 7994 - releases all BGP resources, 7995 - drops the TCP connection, 7996 - changes its state to Idle. 7997 If the Open Delay timer is not running, the local system: 7998 - resets the connect retry timer (sets to zero), 7999 - releases all BGP resources, 8000 - drops the TCP connection, 8001 - increments the ConnectRetryCnt (connect retry count) by 1, 8002 - optionally performs peer oscillation damping, and 8003 - changes its state to Idle. 8005 N.B. This is now event 24 (see issue 26). 8007 We are at consensus with this. 8009 This was discussed in the "Comments 21-30" thread: Comment #25. This 8010 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 8012 3.45 Event 17 in the Connect state 8014 Status: Consensus 8015 Change: Yes 8016 Summary: Adopt text at the end of the discussion section. 8018 Discussion: 8020 This began with Siva asking: 8022 If the transport connection fails (timeout or transport 8023 disconnect) [Event17], the local system: 8024 - changes its state to Active. 8026 If the transport connection fails when the Open Delay timer 8027 [original: BGP Open Delay timer] is running, should we still be 8028 going into the Active state ? 8030 Sue replied referring to the discussion tracked in issue 13.4. 8032 Jeff responded that: 8034 In this particular case, I think the issue is separate from the 8035 issues for events 13-17 since this isn't particular to how deep the 8036 BGP implementation meddles in the TCP implementation. 8038 If we are in the Connect state, because we have an incoming 8039 transport connection that has completed, but we have the OpenDelay 8040 timer running and the transport connection is closed, we can simply 8041 drop into Active after resetting the ConnectRetry timer and clearing 8042 the OpenDelay timer (if set/exists). In the case of an unconfigured 8043 peer, we can discard the FSM instance. 8045 Tom replied that he agreed with this. 8047 Tom then proposed this text: 8049 If the TCP connection fails[Event 17] and the Open Delay 8050 timer is running, the local system: 8051 - restarts the connect retry timer, 8052 - clears the Open Delay timer 8053 - continues to listen for a connection that may be 8054 initiated by the remote BGP peer, and 8055 - changes its state to Active. 8057 If the TCP connection fails [Event17] and the Open Delay 8058 timer is not running, the local system: 8059 - drops the TCP connection, 8060 - releases all BGP resources, 8061 - sets ConnectRetryCnt (the connect retry count) to zero 8062 - resets the connect retry timer (sets to zero), and 8063 - goes to Idle state. 8065 to replace 8067 If the TCP connection fails (timeout or disconnect) 8068 [Event17], the local system: 8069 - restarts the connect retry timer, 8070 - continues to listen for a connection that may be 8071 initiated by the remote BGP peer, and 8072 - changes its state to Active. 8074 Sue agreed to change the text to reflect the comments. 8076 Jeff brought out a couple of other concerns, and Tom replied: 8078 > If the TCP connection fails [Event17] and the Open Delay 8079 > timer is not running, the local system: 8080 > - drops the TCP connection, 8081 > - releases all BGP resources, 8083 There are no resources to release while in the connect state. 8084 (Unless we're using this as shorthand for something else - I 8085 forget.) 8087 Tom: 8089 I was unsure about this action. It is present for Active state 8090 event 17 which is why I put it in, it does include sub-actions such 8091 as clear Open Delay timer (not running), clear Connect Retry timer 8092 (could be running) so I think it right to play safe and include it. 8094 Jeff: 8096 > - sets ConnectRetryCnt (the connect retry count) to zero 8098 I'm forgetting if this action is consistent with everything else. 8099 I don't have a current copy of the FSM and I don't trust -18 to be 8100 current enough. :-) 8102 This said, why do we go to zero? I could see not incrementing it 8103 and letting the normal decay process deal with it. The same would 8104 apply for the above. 8106 Tom: 8108 Again, I was unsure about this so put it in and waited for comment. 8109 I have a chart of 27 events and 6 states in which I have colored in 8110 the connect retry and peer oscillation damping actions and it looks 8111 like measles; I could not divine the underlying logic. Incrementing 8112 the connect retry count would make as much if not more sense to me. 8113 (It is zeroed for Manual Stop). 8115 But the action '[optionally] perform peer oscillation damping' is 8116 yet more erratic (eg for event 10 - Hold Timer expired - it is 8117 performed exiting Connect, Active, Established but not Open Confirm 8118 or Open Sent) so I left it out. Again, it might make more sense put 8119 it in. 8121 Sue replied to this: 8123 The connect state could have a few resources 8124 (minimum peer footprint) as the FSM goes 8125 from Idle to Connected state. While this amount 8126 of BGP resources is not as much as the final 8127 amount, it still needs to get released. 8129 2nd - I think the ConnectRetry count should be removed; 8130 Thanks for catching that. 8132 Please confirm that part #1 is OK with you so we can 8133 put issue 45 into consensus state. 8135 Sue accepted Tom's solution, for the following text: 8137 If the TCP connection fails [Event18], the local system checks 8138 the Open Delay Timer. If the Open Delay timer is running, 8139 the local system: 8140 - restarts the connect retry timer, 8141 - stops the Open Delay timer and resets value to zero, 8142 - continues to listen for a connection that may be 8143 initiated by the remote BGP peer, and 8144 - changes its state to Active. 8145 If the open Delay timer is not running, the local system: 8146 - resets the connect retry timer (sets to zero), and 8147 - Drops the TCP connection, 8148 - Releases all BGP resources, 8149 - and goes to Idle State. 8151 N.B. This is now event 18 (see issue 26). 8153 We are at consensus with this. 8155 This was discussed in the "Comments 21-30" thread: Comment #26. This 8156 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 8158 3.46 Handling of Event 17 in Active state 8160 Status: Consensus 8161 Change: No 8162 Summary: See issue 13.4, this issue closed in favor of that one. 8164 Discussion: 8166 This began with Siva saying: 8168 We should now move into Idle state. Can we add 8170 % - Goes to Idle state 8172 Sue replied that she thought this should be bundled in with the issue 8173 tracked in 13.4. Since no one objected, this issue has been closed 8174 in favor of that one. 8176 This was discussed in the "Comments 21-30" thread: Comment #27. 8178 3.47 Handling of Event 19 in Active state 8180 Status: Consensus 8181 Change: Yes 8182 Summary: Add the new text in the discussion section. 8184 Discussion: 8186 This began with Siva suggesting: 8188 > - Set the Hold timer to a large value (4 minutes), 8190 Since OPEN messages have been exchanged, can we change this to 8192 - If the negotiated Hold time is not 0, set the Hold time to 8193 - the negotiated value 8195 Sue replied that: 8197 The text in Active and Open Sent needs to be the same. 8198 The text in Open Sent is: 8199 - sets the Hold timer according to the negotiated value 8200 (see section 4.2), and 8202 Which text do you prefer? 8204 Sue replied that this text would be added to the next draft: 8206 New text 8208 - if the hold timer value is non-zero, 8209 - starts the keepalive timer to initial value, 8210 - resets the hold timer to the negotiated value, 8211 - else if the hold timer is zero 8212 - resets the keepalive timer (set to zero), 8213 - resets the hold timer to zero. 8215 This seems to address Siva's concerns, this issue is at consensus, if 8216 there are objections, we can reopen it. 8218 This was discussed in the "Comments 21-30" thread: Comment #28. This 8219 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 8221 3.48 Handling of Event 2 in Active state 8223 Status: Consensus 8224 Change: Yes 8225 Summary: Update the draft with the text at the end of the discussion 8226 section. 8228 Discussion: 8230 Siva opened with: 8232 > A manual stop event[Event2], the local system: 8233 > - Sends a notification with a Cease, 8234 > - drops the Transport connection 8236 These two actions are possible only if a transport connection had 8237 already been established. How about changing the text to 8239 % - If a transport connection had been successfully established 8240 % - Send a Notification with a Cease 8241 % - Drop the Transport Connection 8243 Sue counter suggested: 8245 A manual stop event [Event 2], the local system 8246 - Drop the TCP connection, 8247 - Release all BGP resources, 8248 - resets the connection retry timer [sets to zero], 8249 - goes to Idle. 8251 Jeff replied: 8253 I'm rather confused. Under exactly what circumstances can we be 8254 in the Active state and have an active TCP connection at all? 8255 Ditto for having any BGP resources? 8257 Going to Idle is fine. 8259 Tom offered this example: 8261 eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK 8262 received, Delay Open flag set and there we are. Most events are now 8263 possible either from a well-implemented remote peer or a badly 8264 implemented remote peer. 8266 Sue asked if there were any additional comments, if not, the text 8267 will be: 8269 A manual stop event[Event2], the local system: 8270 - Sends a NOTIFICATION with a Cease, 8271 - releases all BGP resources including 8272 - stopping the Open delay timer 8273 - drops the TCP connection, 8274 - sets ConnectRetryCnt (connect retry count) to zero 8275 - resets the connect retry timer (sets to zero), 8276 - changes its state to Idle. 8278 There have been no additional comments, we will use the text Sue 8279 proposed. 8281 This was discussed in the "Comments 21-30" thread: Comment #29. This 8282 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 8284 3.49 Default Event handling in Active state 8286 Status: Consensus 8287 Change: No 8288 Summary: No routes in active. 8290 Discussion: 8292 Siva began with: 8294 To ensure consistency with E2 handling, can we add 8296 % - If any BGP Routes exist, delete the routes 8298 Sue replied: 8300 Comment: Yakov and Jeff noted, there are no routes in Active state. 8302 Since there were no responses disagreeing, we'll consider this closed 8303 unless someone wants to open it back up. 8305 This was discussed in the "Comments 21-30" thread: Comment #30. 8307 3.50 Clearing Hold timer in OpenSent, OpenConfirm and Established State 8309 Status: Consensus 8310 Change: No 8311 Summary: This issue is addressed in the "Clear BGP resources" 8313 Discussion: 8315 This began with Siva stating: 8317 In all event handling where we go to Idle state, we need to clear 8318 the Hold Timer as well. 8320 Sue replied that: 8322 issue resolve one way last Jan - March 8323 Clearing of keep alive timer included 8324 in Clear BGP resources 8326 No response to this yet, but since this seems to be resolved it is at 8327 consensus unless someone objects. 8329 This was discussed in the "Comments 30-36" thread: Comment #31. 8331 3.51 Clearing Keepalive timer in OpenConfirm and Established State 8333 Status: Consensus 8334 Change: No 8335 Summary: This issue is addressed in the "Clear BGP resources" 8337 Discussion: 8339 This began with Siva stating: 8341 In all event handling where we go to Idle state, we need to clear 8342 the Keepalive Timer as well. 8344 Sue replied that: 8346 issue resolve one way last Jan - March 8347 Clearing of keep alive timer included 8348 in Clear BGP resources 8350 No response to this yet, but since this seems to be resolved it is at 8351 consensus unless someone objects. 8353 This was discussed in the "Comments 30-36" thread: Comment #32. 8355 3.52 Handling Event 18 in the OpenSent state (Keepalive Timer) 8357 Status: Consensus 8358 Change: Yes 8359 Summary: Make the event optional. 8361 Discussion: 8363 This began with Siva asking: 8365 Why do we start the Keepalive timer at this stage ? Isn't it 8366 sufficient to do so when we move into Established state ? 8368 Sue replied: 8370 An earlier comment from Tom (and you) requested the following: 8372 <---Open 8373 [Open sent state] 8375 Open--> 8376 [Event 18] 8378 <---Open 8379 <---Keepalive 8380 [Action from Event 18 in Open Sent] 8381 [Open Confirm] 8382 Keepalive -> [Event 25] 8384 [established] 8386 What do implementations do? We'll have to query implementations. 8388 Jeff added: 8390 I'm assuming the second OPEN going from right to left is a typo. 8391 If it isn't, thats a FSM error to the peer on the left. 8393 Theoretically, an implementation that utilizes its keepalive timer 8394 to send the first keepalive to transition to Established is 8395 still interoperable. However: 8397 o Keepalives can be disabled by negotiating hold time of zero 8398 o We really shouldn't need to restart the Keepalive timer. 8399 If there is a delay in the keepalive that transitions from 8400 OpenConfirm to Established, its due to the transport connection. 8401 It should be reliable and it *should* get through. If it 8402 doesn't, there's other problems and the hold timer for the 8403 peer on the right should do the Right Thing and drop the 8404 connection. 8406 > What do implementations do? We'll have to query implementations. 8408 GateD at least waits to enter the Established state prior to 8409 starting the KeepAlive timer. 8411 Tom also added: 8413 My comment was that if we do not send a KeepAlive (and start the 8414 KeepAlive timer), on exiting from Active with Event 19 to 8415 OpenConfirm then we never will and the connection will die. Open 8416 Confirm state means valid Open received so we must send a KeepAlive 8417 to acknowledge the Open (as pointed out in Jeff's other posting) 8418 and we never do it in OpenConfirm state itself (unless the KeepAlive 8419 timer expires which it cannot because we have not started it). 8421 So for me, OpenSent state Event 18 was and is correct, sending the 8422 KeepAlive without which the connection goes no further and Active 8423 state Event 19 needs to be brought into line. 8425 To say that the timer is started when entering Established state is 8426 fine except for a slight problem; we have no way in this FSM of 8427 defining actions that are taken on entering a state, only actions to 8428 be taken on leaving another state so that is why the KeepAlive 8429 actions need to be where they are (or are not in the case of Active 8430 state Event 19). 8432 Sue replied, asking more implementors to chime in on what they do for 8433 this part of the FSM. 8435 Curtis replied that we should: 8437 Make it optional. Timing out in open or open-sent has never been 8438 much of an issue, so whether one or three keepalive get sent 8439 shouldn't be a hot topic. 8441 Sue said that this was fine, and she would work on text specifying 8442 optional. 8444 Jeff replied regarding GateD's behavior: 8446 GateD will start its keepalive timer while in this state, so 8447 multiple keepalives will be sent. 8449 As someone previously said, this is a "yawn" issue. But to choose 8450 one way or the other, we may potentially make someone in non- 8451 compliance. 8453 From the closure of issue 12, we have this text, which discusses 8454 Keepalives to consider in relation to the other keepalive issue here: 8456 Change 1: new text 8458 Active state - event 19 8460 If an Open is received with the Open Delay timer is 8461 running [Event 19], the local system 8462 - clears the connect retry timer (cleared to zero), 8463 - stops and clears the Open Delay timer 8464 - completes the BGP initialization, 8465 - stops and clears the Open Delay timer 8466 - sends an OPEN message, 8467 - send a Keepalive message, 8468 - if the hold timer value is non-zero, 8469 - starts the keepalive timer to initial value, 8470 - resets the hold timer to the negotiated value, 8471 else if the hold timer is zero 8472 - resets the keepalive timer (set to zero), 8473 - resets the hold timer to zero. 8475 - changes its state to OpenConfirm. 8477 If the value of the autonomous system field is the same as the 8478 local Autonomous System number, set the connection status to an 8479 internal connection; otherwise it is "external". 8481 Since there were no more comments, this is at consensus. 8483 This was discussed in the "Comments 30-36" thread: Comment #33. And 8484 in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State 8485 (Keepalive timer set)" thread. 8487 3.53 Established State MIB 8489 Status: Consensus 8490 Change: No 8491 Summary: MIB references pulled in favor of having them in the MIB 8492 document. 8493 See issue 8. 8495 Discussion: 8497 This began with Siva asking: 8499 Some event handling in the Established state do not set the MIB 8500 Reason when handling an event that causes an error. Can we add this 8501 ? 8503 Sue replied that we have pulled the MIB wording from the FSM. See 8504 issue 8. 8506 This was discussed in the "Comments 30-36" thread: Comment #34. 8508 3.54 State impact of not supporting Optional Events 8510 Status: Consensus 8511 Change: Yes 8512 Summary: Add the text at the end of the discussion section. 8514 Discussion: 8516 Siva stated that: 8518 For the events whose status is optional, can we state the impact of 8519 not supporting them (in terms of any interoperability issues). I 8520 understand that most of the optional events will not have such an 8521 impact; but a clarification statement for the optional events would 8522 benefit new implementors. 8524 Sue responded: 8526 Much of the support of optional parameters depends on policy. 8527 I could put a short note about the optional events and 8528 parameters as part of 8.1.5 or 8.2.1.3 8530 I think it fits better in 8.1.5. 8532 Optional: Events: 3-8, 12, 13-14[my suggestion] 8533 19, 22 8535 Timers: Idle Hold Timer 8536 Open Delay Timer 8538 Required flags for optional parameters: 8540 Open Delay Flag 8541 BGP Stop Flap 8543 Sue said she would try to work up more if it is agreed that this is 8544 on the right track. 8546 Sue provided this text to clarify the behavior associated with 8547 Optional Attributes: 8549 8.2.1.3 FSM and Optional Attributes 8551 Optional Attributes specify either flags that augment the normal 8552 processing of the BGP FSM, or optional timers. If a Optional 8553 attribute can be set on a system, the Events and the BGP FSM actions 8554 must be support. For example, if the following options can 8555 be set in a BGP implementation: AutoStart and Passive TCP connection 8556 Establishment flag, then the events 3, 4 and 5 must be supported. 8558 If an Optional attribute cannot be set (that is declared always off 8559 logically), the events supporting that set of options do not 8560 have to be supported. 8562 This was discussed in the "Comments 30-36" thread: Comment #35. 8564 3.55 New DelayOpen State 8566 Status: Consensus 8567 Change: No 8568 Summary: We've chosen not to reopen the debate about adding a 8569 DelayOpen State to the FSM. 8571 Discussion: 8573 Siva began with asking: 8575 Is delaying the sending of an OPEN message a standard industry 8576 practice ? 8578 Also, in the FSM, this has been handled by practically implementing 8579 a sub-state each, within the CONNECT and ACTIVE states. Won't the 8580 FSM look more simple if we just had a new DelayOpen state that we 8581 could move into ? 8583 Sue responded that this was something we have tried to do before, but 8584 that it spawned some degree of rabid response on both sides. Given 8585 our current mandate to stick with what is implemented, it is probably 8586 best not to reopen this debate. 8588 Unless someone badly wants to reopen this debate, the issue is at 8589 Consensus. 8591 This was discussed in the "Comments 21-30" thread: Comment #22. 8592 This was discussed in the "Comments 21-30" thread: Comment #26. 8593 This was discussed in the "Comments 30-36" thread: Comment #36. 8595 3.56 Clarify what is covered in the base document. 8597 Status: Consensus 8598 Change: Yes 8599 Summary: Add the text at the end of the discussion to clarify what is 8600 documented where with regard to BGP and its extensions. 8602 Discussion: 8604 This grew out of a discussion on how to use BGP Identifiers in an 8605 IPv6-only environment. In that discussion it became clear that the 8606 way the documents are currently structured it is not clear to new 8607 readers that extension specifications can and do specify behavior 8608 that supersedes the behavior specified in the base spec. To that end 8609 it was agreed that this text should be added: 8611 This document specifies the base behavior of the BGP protocol. 8612 This behavior can and is modified by extension specifications. 8613 When the protocol is extended the new behavior is fully documented 8614 in the extension specifications. 8616 This was discussed in the "Next-Hop in IPv6 only environments" 8617 thread. 8619 4. References 8621 [RFC1771] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", 8622 RFC 1771, March 1995. 8624 [BGP4Draft] Rekhter, Y., Lo, T., Hares, S., "A Border Gateway 8625 Protocol 4 (BGP-4)", work-in-progress, draft-ietf-idr-bgp4-20.txt. 8627 5. Author's Address: 8629 Andrew Lange 8630 Cable & Wireless 8631 1215 Borregas Ave. 8632 Sunnyvale, CA 94089 8633 andrewl@cw.net