idnits 2.17.1 draft-ietf-idr-bgp-issues-00.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 2407 has weird spacing: '...covered here ...' == Line 3004 has weird spacing: '...setting any B...' == Line 3029 has weird spacing: '...setting any B...' == Line 4923 has weird spacing: '...ing the follo...' == Line 5177 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 (November 2003) is 7467 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 205, but not defined == Missing Reference: 'N' is mentioned on line 923, but not defined == Missing Reference: 'RWStevens' is mentioned on line 1293, but not defined == Missing Reference: 'RFC2385' is mentioned on line 4100, 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 1829 == Missing Reference: 'RFC904' is mentioned on line 6404, but not defined -- Looks like a reference, but probably isn't: '12' on line 3032 -- Looks like a reference, but probably isn't: '10' on line 4089 == Missing Reference: 'RFC793' is mentioned on line 4097, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) -- Looks like a reference, but probably isn't: '13' on line 4653 == Missing Reference: 'Event17' is mentioned on line 8083, but not defined == Missing Reference: 'Event 18' is mentioned on line 8381, but not defined == Missing Reference: 'Event 19' is mentioned on line 8466, but not defined == Missing Reference: 'Event 14' is mentioned on line 7634, but not defined == Missing Reference: 'Event 13' is mentioned on line 6036, but not defined == Missing Reference: 'Event 17' is mentioned on line 8054, but not defined == Missing Reference: 'Event 22' is mentioned on line 6060, but not defined == Missing Reference: 'Event 15' is mentioned on line 6037, but not defined == Missing Reference: 'RFC3065' is mentioned on line 6227, but not defined ** Obsolete undefined reference: RFC 3065 (Obsoleted by RFC 5065) == Missing Reference: 'Event 1' is mentioned on line 7003, but not defined == Missing Reference: '3-6' is mentioned on line 7012, but not defined == Missing Reference: 'Event1' is mentioned on line 7012, but not defined == Missing Reference: 'Event24' is mentioned on line 7995, but not defined == Missing Reference: 'Event18' is mentioned on line 8142, but not defined == Missing Reference: 'Event2' is mentioned on line 8274, but not defined == Missing Reference: 'Event 2' is mentioned on line 8250, but not defined == Missing Reference: 'Event 25' is mentioned on line 8387, but not defined == Unused Reference: 'RFC1771' is defined on line 8626, but no explicit reference was found in the text == Unused Reference: 'BGP4Draft' is defined on line 8629, 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 May 2003 5 Expires November 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.................... 80 2.29 State Why Unresolveable Routes Should Be Kept in 81 Adj-RIB-In............................................. 82 2.30 Mention Other Message Types............................ 83 2.31 Add References to Additional Options................... 84 2.32 Clarify EGP Reference.................................. 85 2.32.1 EGP ORIGIN Clarification............................. 86 2.32.2 BGP Destination-based Forwarding Paradigm............ 87 2.33 Add "Optional Non-Transitive" to the MED Section....... 88 2.34 Timer & Counter Definition............................. 89 2.35 Fix Typo............................................... 90 2.36 Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 91 2.37 Combine "Unfeasible Routes" and "Withdrawn Routes"..... 92 2.38 Clarify Outbound Route Text............................ 93 2.39 Redundant Sentence Fragments........................... 94 2.40 Section 9.2.1.1 - Per Peer vs. Per Router 95 MinRouteAdvertisementInterval.......................... 97 2.41 Mention FSM Internal Timers............................ 98 2.42 Delete the FSM Section................................. 99 2.43 Clarify the NOTIFICATION Section....................... 100 2.44 Section 6.2: OPEN message error handling............... 101 2.45 Consistent References to BGP Peers/Connections/Sessions 102 2.46 FSM Connection Collision Detection..................... 103 2.47 FSM - Add Explicit State Change Wording................ 104 2.48 Explicitly Define Processing of Incoming Connections.. 105 2.49 Explicitly Define Event Generation...................... 106 2.50 FSM Timers............................................. 107 2.51 FSM ConnectRetryCnt.................................... 108 2.52 Section 3: Keeping routes in Adj-RIB-In................ 109 2.53 Section 4.3 - Routes v. Destinations - Advertise....... 110 2.54 Section 4.3 - Routes v. Destinations - Withdraw........ 111 2.55 Section 4.3 - Description of AS_PATH length............ 112 2.56 Section 6 - BGP Error Handling......................... 113 2.57 Section 6.2 - Hold timer as Zero....................... 114 2.58 Deprecation of ATOMIC_AGGREGATE........................ 115 2.59 Section 4.3 - Move text................................ 116 2.60 Section 4.3 - Path Attributes.......................... 117 2.61 Next Hop for Redistributed Routes...................... 118 2.62 Deprecate BGP Authentication Optional Parameter from 119 RFC1771................................................ 120 2.63 Clarify MED Removal Text............................... 121 2.64 MED for Originated Routes.............................. 122 2.65 Rules for Aggregating with MED and NEXT_HOP............ 123 2.66 Complex AS Path Aggregating............................ 124 2.67 Counting AS_SET/AS_CONFED_*............................ 125 2.68 Outbound Loop Detection................................ 126 2.69 Appendix A - Other Documents........................... 127 3.1 Reference to RFC 1772................................... 128 3.2 MUST/SHOULD Capitalization.............................. 129 3.3 Fix Update Error Subcode 7 -- accidently removed........ 130 3.4 Section 5.1.4 - Editorial Comment........................ 131 3.5 Section 9.1 - Change "all peers" to "peers"............. 132 3.6 AS Loop Detection & Implicit Withdraws.................. 133 3.7 Standardize FSM Timer Descriptions...................... 134 3.8 FSM MIB enumerations.................................... 135 3.9 Make "delete routes" language consistent................ 136 3.10 Correct OpenSent and OpenConfirm delete wording........ 137 3.11 Incorrect next state when the delay open timer expires. 138 3.12 Entering OpenConfirm / Adding "Stop OpenDelay" action.. 139 3.13 FSM Missing Next States................................ 140 3.13.1 FSM Missing Next States - Event 15 or 16 141 (Connect State)...................................... 142 3.13.2 FSM Missing Next States - Event 14 (Connect State)... 143 3.13.3 FSM Missing Next States - Event 15 or 16 144 (Active State)....................................... 146 3.13.4 FSM Missing Next States - Event 13-17 147 (TCP Connection)..................................... 148 3.13.5 FSM Missing Next States - Event 17 (Connect State)... 149 3.13.6 FSM Missing Next States - Event 18 (Open Confirm).... 150 3.14 FSM - Peer Oscillation Damping......................... 151 3.15 FSM - Consistent FSM Event Names....................... 152 3.16 Many Editorial Comments................................ 153 3.17 Section 3, Page 8, Paragraph 3 - Obsolete?............. 154 3.18 MED Removal Text....................................... 155 3.19 Security Considerations................................ 156 3.20 Peer Oscillation Damping............................... 157 3.21 Session Attributes - IdleHold Timer.................... 158 3.22 Specify New Attributes (Accept Connections/Peer 159 Oscillation Damping)................................... 160 3.23 Event1/Event2 Clean Up................................. 161 3.24 Events 3, 5, 6 & 7 Give Examples....................... 162 3.25 Event 4 & 5 Session Initiation Text.................... 163 3.26 Event 4 & 5 - bgp_stop_flap option..................... 164 3.27 Event 5 Clarification.................................. 165 3.28 Timer Events Definition - Make Consistent.............. 166 3.29 Event 8 - Clean Up..................................... 167 3.30 Hold Timer - Split?.................................... 168 3.31 OpenDelay Timer Definition............................. 169 3.32 Definition of TCP Connection Accept (Event 13)......... 170 3.33 Event 13 & 14 - Valid Addresses & Ports................ 171 3.34 Event 17 - TCP Connection Fails to TCP Connection 172 Termination............................................ 173 3.35 Making Definition Style Consistent..................... 174 3.36 Event 19 - Definition Cleanup.......................... 175 3.37 Event 22 - Cleanup..................................... 176 3.38 FSM Description - ConnectRetry Count................... 177 3.39 Handling Event 7 (Auto Stop to Idle State processing).. 178 3.40 Clearing the Connection Retry Timer.................... 179 3.41 Handling of Event 14 in the Connect State.............. 180 3.42 Handling events 20, 21 in the Connect State and Active 181 State.................................................. 182 3.43 Handling the default events in the Connect state....... 183 3.44 Handling Event 23 in Connect and OpenSent.............. 184 3.45 Event 17 in the Connect state.......................... 185 3.46 Handling of Event 17 in Active state................... 186 3.47 Handling of Event 19 in Active state................... 187 3.48 Handling of Event 2 in Active state.................... 188 3.49 Default Event handling in Active state................. 189 3.50 Clearing Hold timer in OpenSent, OpenConfirm and 190 Established State...................................... 191 3.51 Clearing Keepalive timer in OpenConfirm and Established 192 State.................................................. 193 3.52 Handling Event 18 in the OpenSent state (Keepalive 194 Timer)................................................. 195 3.53 Established State MIB.................................. 196 3.54 State impact of not supporting Optional Events......... 197 3.55 New DelayOpen State.................................... 198 3.56 Clarify what is covered in the base document........... 200 Specification of Requirements 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in RFC 2119 [RFC2119]. 206 1. Introduction 208 This document records the issues discussed and the consensus reached 209 in the Interdomain Routing (IDR) Working Group during its efforts to 210 revise and bring up to date the base specification for the BGP-4 211 protocol. The rational for doing this is simple: Experience has 212 demonstrated that the same issues and questions tend to come up again 213 and again. This memo will document not only the decisions on these 214 issues but also how and why the working group reached those 215 conclusions. We hope that this will help make future discussions 216 more fruitful by providing them with a historical context. 218 This document traces the evolution of the BGP-4 base specification 219 from its incarnation as draft-ietf-idr-bgp4-17.txt through the big 220 revision and update push culminating in draft-ietf-idr-bgp4-19.txt. 221 It is divided into two main sections. The first deals with the 222 issues discussed between -17 and -18, and the second deals with the 223 issues discussed between -18 and -19. 225 N.B. There is no rhyme or reason to the numbering scheme other than 226 unique tags to address the issues. 228 2. The Issues from -17 to -18. 230 This section lists the issues discussed on the list from late August 231 to late October 2002. 233 2.1 IDR WG Charter 235 Status: Consensus 236 Change: Yes 237 Summary: New charter adopted. 239 Discussion: 241 A variety of discussions surrounded the new charter. The rough 242 consensus is to accept the new charter that the AD's have proposed, 243 and to push as hard a possible to get the base spec to RFC status so 244 other drafts that are dependent can also move forward. 246 For our information, Alex has provided these approximate time lines: 248 Stage Anticipated delay Comment 249 -------------------------------------------------------------------- 250 AD-review 1-4 weeks The document may go back 251 depending on to the WG for the 252 workload AD-review comments to be 253 addressed; this would 254 introduce additional 255 delay. 257 IETF LC 2 weeks Same as above 259 IESG review & 1-2 weeks depending Same as above 260 telechat on when the IETF LC ends 261 -------------------------------------------------------------------- 263 Note that if the document is sent back to the WG at some stage, 264 required changes may warrant an additional WG Last Call. 266 I can personally commit to a 2-week upper bound for the AD-review 267 period. Bill may have a different timer granularity. 269 The opinions expressed on this were 7 in favor, 4 against. 271 This thread has messages subjects of "BGP spec and IDR WG charter" 272 and "IDR WG charter". 274 2.2 TCP Port 276 Status: Consensus 277 Change: Yes 278 Summary: 279 Change: "BGP uses TCP port 179 for establishing its connections." 280 To: "BGP listens on TCP port 179." 282 Discussion: 284 There has been a discussion on clarifying the wording in Section 2, 285 on which port BGP uses. The original text was: 287 "BGP uses TCP port 179 for establishing its connections." 289 The proposed new text is: 291 "BGP listens on TCP port 179." 293 There seems to be a rough consensus that the new text is better. 295 This thread has a message subject of "Review: Section 2, TCP Port 296 179" 298 2.3 FSM wording for what state BGP accepts connections in 300 Status: Consensus 301 Change: No 302 Summary: No change necessary 304 Discussion: 306 An issue was brought up later in the "Review: Section 2, TCP Port 307 179" thread about the words in the FSM for what state BGP accepts 308 connections in. The consensus is that the existing wording is clear. 310 2.4 BGP Identifier/Router ID 312 Status: Consensus 313 Change: No 314 Summary: No change necessary to base draft. Perhaps in a BCP. 316 Discussion: 318 The "admin dist/gp spec proposal", "Router ID" and "bgp spec 319 proposal" threads discussed the BGP Identifier and how close or not 320 it is to IGP's Router ID. The consensus was that this discussion is 321 better saved for a BCP draft, and that it does not need to be 322 contained in the base spec. 324 2.5 Direct EBGP Peers 326 Status: Consensus 327 Change: No 328 Summary: A recollection that ebgp peers must be direct. No text 329 proposed, no discussion. 331 Discussion: 333 Jonathan recalled something that stated that ebgp peers must be 334 direct. No specific sections were quoted. 336 Yakov responded to this with: 338 Section 5.1.3 talks about both the case where ebgp peers are 1 IP hop 339 away from each other: 341 2) When sending a message to an external peer X, and the peer is one 342 IP hop away from the speaker: 344 as well as the case where they are multiple IP hops away from each 345 other: 347 3) When sending a message to an external peer X, and the peer is 348 multiple IP hops away from the speaker (aka "multi hop EBGP"): 350 And emphasized that multi hop EBGP does exist. 352 This came up in the "bgp draft review" thread. 354 2.6 Disallow Private Addresses 356 Status: Consensus 357 Change: No 358 Summary: No change necessary 360 Discussion: 362 In the tread entitled "bgp draft review": 364 Mentioned explicitly disallowing private addresses. The consensus 365 was that there is no reason to disallow them. Which IP addresses 366 peers use is an operational issue. 368 2.7 Renumber Appendix Sections 370 Status: Consensus 371 Change: Yes 372 Summary: Rename/renumber appendix sections so they do not have the 373 same numbers as sections of the main text. 375 Discussion: 377 In the tread entitled "bgp draft review": 379 This thread brought up renaming sections in the appendix to avoid 380 confusion with sections of the same number in the main text. 382 Yakov responded that he would do so in the next edition. 384 2.8 Jitter Text 386 Status: Consensus 387 Change: Yes 388 Summary: 389 Get rid of section 9.2.1.3 ("Jitter"). Move the text to an 390 Appendix: "BGP Timers" Expand text to indicate that jitter applies 391 to all timers, including ConnectRetry. 393 The text for the appendix is listed at the end of the discussion. 395 Discussion: 397 In the tread entitled "bgp draft review": The thread also proposed: 399 "jitter should be applied to the timers associated with 400 MinASOriginationInterval, Keepalive, and 401 MinRouteAdvertisementInterval" 403 Be changed to: 405 "jitter should be applied to the timers associated with ConnectRetry 406 timer" 408 Yakov agreed with making some changes and suggested that we make sure 409 that jitter is applied to all timers. Specifically, he proposes we 410 get rid of section 9.2.1.3 ("Jitter"), move the text of this section 411 into Appendix "BGP Timers", and expand the text to indicate that 412 jitter applies to ConnectRetry timer as well. 414 Jonathan, the original commenter, agreed with Yakov's suggestion. 416 In a follow-up to this issue, there was a question raised about the 417 values we have specified for timers in the document. Specifically: 419 The ConnectRetry timer is should have a value that is 'sufficiently 420 large to allow TCP initialization. Application of jitter can reduce 421 the this value (by up to 25%). A configuration which the ConnectRetry 422 timer has been pegged at a value close to TCP connection time may 423 cause a connection to be terminated as a result of this jitter. Is 424 this a cause for concern ? 426 The default value suggested for ConnectRetry (120 seconds) is 427 sufficiently large that event with a jitter of 0.75, it will be 428 greater than TCP's connection establishment timer. 430 Is adding a jitter to the ConnectRetry timer a standard practice ? 431 What benefit does this provide ? 433 Curtis responded to this with: 435 The TCP connection establishment timer is 75 seconds (sysctl yield 436 "net.inet.tcp.keepinit: 75000" in BSD-oids). 438 The ConnectRetry determines when to make a second attempt after a 439 prior attempt to connect has failed. It is to avoid a rapid 440 succession of retries on immediate failures (for example "Connection 441 refused" if the peer was in the middle of a reboot, Network 442 Unreachable if you can't get there from here, etc) but also covers 443 the case where the TCP SYN goes off and is never heard from again. 445 And Jonathan replied with this information about current practice: 447 It seems to me that if you bring up all bgp peers at once it may lead 448 to load spikes on the network. Cisco seems to wait 27.5 +/- 2.5 449 seconds for IBGP, and 40 +/- 5 seconds for EBGP--20 sec. from config 450 time to the "open active, delay" jittered delay assignment plus the 451 jittered delay (5 to 10 sec. for IBGP, and 15 to 25 sec. for EBGP). 452 This would also apply for "no neighbor x.x.x.x shutdown". Their 453 value of ConnectRetry is 60sec. though, not sure how this value is 454 used (based on above). Maybe some Cisco folks can chime in on this 455 one??? 457 I did not check Juniper. 459 Also, interestingly, they do not apply jitter to the other timers (as 460 far as I can tell), but I don't see a problem with this. 462 Another timer that they use that is not mentioned in the draft/rfc is 463 the next hop resolution timer which is 30 seconds. Although it would 464 be nice to have this in the spec, I will concede that it is out of 465 scope and/or implementation dependent. 467 So the question that arises from this followup, is how does this 468 question affect the text of the appendix on jitter? 470 Curtis replied that we need to only state that jitter should be 471 applied to all timers. Whether a vendor does so or not is a minor 472 deficiency and does not bear on interoperability. Therefore, 473 specifying exact details are not necessary. 475 After Jonathan's response Curtis and Jonathan agreed that jitter 476 should be added to all timers and that we should state so in the 477 text. 479 Yakov proposed the following text for the appendix to discuss jitter: 481 I'd like to propose the following text for "BGP Timers" section: 483 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 484 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 485 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 486 9.2.1.1). 488 The suggested value for the ConnectRetry timer is 120 seconds. 490 The suggested value for the Hold Time is 90 seconds. 492 The suggested value for the KeepAlive timer is 1/3 of the Hold Time. 494 The suggested value for the MinASOriginationInterval is 15 seconds. 496 The suggested value for the MinRouteAdvertisementInterval is 30 497 seconds. 499 An implementation of BGP MUST allow the Hold Time timer to be 500 configurable, and MAY allow the other timers to be configurable. 502 To minimize the likelihood that the distribution of BGP messages by a 503 given BGP speaker will contain peaks, jitter should be applied to the 504 timers associated with MinASOriginationInterval, Keepalive, 505 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 506 shall apply the same jitter to each of these quantities regardless of 507 the destinations to which the updates are being sent; that is, jitter 508 will not be applied on a "per peer" basis. 510 The amount of jitter to be introduced shall be determined by 511 multiplying the base value of the appropriate timer by a random 512 factor which is uniformly distributed in the range from 0.75 to 1.0. 514 Jeff & Ben agreed with this. 516 Justin suggested that we move the range from 0.75 to 1.25 to ensure 517 that the average is around the configured value. Yakov agreed with 518 Justin's changes. Jonathan disagreed, arguing that it was out-of- 519 scope for the task of clarifying the text only. Justin agreed and 520 withdrew his comment. 522 Curtis liked the general text, but suggested these modifications: 524 minor improvement (not really an objection) -- s/suggested 525 value/suggested default value/g 527 Also 529 s/shall apply the same jitter/may apply the same jitter/ (to each of 530 these quantities regardless of ...). 532 s/jitter will not be applied/jitter need not be configured/ (on a 533 "per peer" basis). 535 He stated that in Avici's implementation they allow a lot of 536 granularity in timer settings, so this reflects current practice. 538 Curtis also suggested changing the last paragraph: 540 The suggested default amount of jitter shall be determined by 541 multiplying the base value of the appropriate timer by a random 542 factor which is uniformly distributed in the range from 0.75 to 1.0. 543 A new random value should be picked each time the timer is set. The 544 range of the jitter random value MAY be configurable. 546 This would make it clear that it is possible to have this timer as 547 configurable and still be within spec. 549 Other comments on Yakov's text pointed out that IOS uses 5 seconds as 550 the default IBGP MinRouteAdvertisementInterval. 552 Tom pointed out that there seems to be a discrepancy between this 553 text and the FSM: The FSM has an OpenDelay timer. And the FSM 554 suggests a HoldTimer of 4 minutes. 556 In following up on this issue, Yakov stated: 558 Here is the final text for the BGP Timers section: 560 BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see 561 Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval 562 (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section 563 9.2.1.1). 565 The suggested default value for the ConnectRetry timer is 120 566 seconds. 568 The suggested default value for the Hold Time is 90 seconds. 570 The suggested default value for the KeepAlive timer is 1/3 of the 571 Hold Time. 573 The suggested default value for the MinASOriginationInterval is 15 574 seconds. 576 The suggested default value for the MinRouteAdvertisementInterval is 577 30 seconds. 579 An implementation of BGP MUST allow the Hold Time timer to be 580 configurable, and MAY allow the other timers to be configurable. 582 To minimize the likelihood that the distribution of BGP messages by a 583 given BGP speaker will contain peaks, jitter should be applied to the 584 timers associated with MinASOriginationInterval, Keepalive, 585 MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker 586 may apply the same jitter to each of these quantities regardless of 587 the destinations to which the updates are being sent; that is, jitter 588 need not be configured on a "per peer" basis. 590 The suggested default amount of jitter shall be determined by 591 multiplying the base value of the appropriate timer by a random 592 factor which is uniformly distributed in the range from 0.75 to 1.0. 593 A new random value should be picked each time the timer is set. The 594 range of the jitter random value MAY be configurable. 596 With this in mind, I would suggest we mark this issue as closed. 598 Jonathan suggested adding "per peer" to the text, Yakov responded 599 with this text: 601 An implementation of BGP MUST allow the Hold Time timer to be 602 configurable on a per peer basis, and MAY allow the other timers to 603 be configurable. 605 This proposal met with general agreement. This issue is at 606 consensus. 608 2.9 Reference to RFC904 - EGP Protocol 610 Status: Consensus 611 Change: Yes 612 Summary: Add a reference to RFC904 614 Discussion: 616 The "Review Comment: Origin Attribute pg 14" thread suggested adding 617 a reference to RFC904(?), to refer to the EGP protocol. There was no 618 discussion. 620 Yakov agreed to this, and Jonathan seconded it. 622 2.10 Extending AS_PATH Attribute 624 Status: Consensus 625 Change: Yes 626 Summary: Add this to 9.2: 628 If due to the limits on the maximum size of an UPDATE message (see 629 Section 4) a single route doesn't fit into the message, the BGP 630 speaker MUST not advertise the route to its peers and may choose to 631 log an error locally. 633 Discussion: 635 The "Extending AS_PATH attribute length en route" thread brought up 636 the issue of what action should we specify when we receive a route 637 with an AS_PATH that exceeds the defined maximum length. There was 638 some discussion, and it was suggested that, after logging the error, 639 the route not be propagated. 641 Yakov stated that: 643 The real issue here is how to handle the case when a route (a single 644 address prefix + path attributes) doesn't fit into 4K bytes (as the 645 max BGP message size is 4 K). To address this issue I would suggest 646 to add the following to 9.2: 648 After some discussion, Yakov's proposed text's last sentence was 649 dropped and we arrived at: 651 If due to the limits on the maximum size of an UPDATE message (see 652 Section 4) a single route doesn't fit into the message, the BGP 653 speaker may choose not to advertise the route to its peers. 655 In response to Andrew's clarification question to the list, Curtis 656 responded: 658 Wording would be more like: 660 If the attributes for a specific prefix becomes too large to fit the 661 prefix into the maximum sized BGP UPDATE message, the prefix should 662 not be advertised further. Truncation or omission of attributes 663 should not occur unless policies for such modifications are 664 specifically configured. Such policies may contribute to the 665 formation of route loops and are not within the scope of this 666 protocol specification. 668 After some additional discussion, it was decided that we add "and may 669 choose to log an error locally." to the end of Yakov's text. 671 Also, we agreed to change "may choose not to advertise..." to "MUST 672 NOT advertise...". 674 So the text on the table right now is: 676 If due to the limits on the maximum size of an UPDATE message (see 677 Section 4) a single route doesn't fit into the message, the BGP 678 speaker MUST not advertise the route to its peers and may choose to 679 log an error locally. 681 This met with one agreement and no disagreements. We have a 682 consensus. 684 2.11 Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 686 Status: Consensus 687 Change: Yes 688 Summary: Add this text: 690 The local speaker SHALL then install that route in the Loc-RIB, 691 replacing any route to the same destination that is currently being 692 held in the Loc-RIB. When the new BGP route is installed in the Rout- 693 ing Table, care must be taken to ensure that existing routes to the 694 same destination that are now considered invalid are removed from the 695 Routing Table. Whether or not the new BGP route replaces an existing 696 non-BGP route in the Routing Table depends on the policy configured 697 on the BGP speaker. 699 Discussion: 701 The "Proxy: comments on section 9.1.3" thread brought up some lack of 702 clarity in the section discussing the rules for which routes get 703 propagated from the Loc-RIB into the Adj-RIB-Out. These discussions 704 resulted in a number of suggestions for new text. 706 The first new text was proposed to clarify the issue that the thread 707 first brought up: 709 I agree that this could use some clarification. How about adding 710 to b) in section 9.1: 712 The Loc-RIB must contain only one route per destination; further, it 713 must include all routes that the BGP speaker is using. 715 changing c) in section 9.1.2 to: 717 c) is selected as a result of the Phase 2 tie breaking rules 718 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." 865 There were a lot of emails exchanged on this topic with a variety of 866 texts proposed (see early in the "Active Route" thread). This issue 867 reopened with Jonathan, who brought up the issue originally, stating 868 that: 870 The issue I raised, and would like to be [re-]considered is with: 872 "one must focus on the rule that a BGP speaker advertises to its 873 peers (other BGP speakers which it communicates with) in neighboring 874 ASs only those routes that it itself uses." 876 Curtis replied that: 878 That is called route origination and it is allowed by: 880 9.4 Originating BGP routes 882 A BGP speaker may originate BGP routes by injecting routing 883 information acquired by some other means (e.g. via an IGP) into BGP. 884 [...] The decision whether to distribute non-BGP acquired routes 885 within an AS via BGP or not depends on the environment within the AS 886 (e.g. type of IGP) and should be controlled via configuration. 888 Advice on what to put in the AS_PATH and NEXT_HOP is in the document. 890 He continued with: 892 I don't think there was ever consensus on what to do with the 893 statement "a BGP speaker advertises to its peers (other BGP speakers 894 which it communicates with) in neighboring ASs only those routes that 895 it itself uses". Some reasonable choices are: 897 1. Omit it (the implied consensus of the rewrite of the paragraph in 898 32.2). 900 2. Leave it as is and put it in another paragraph to separate it 901 from the destination based routing statement. 903 3. Clean up the wording and put it in another paragraph to separate 904 it from the destination based routing statement. 906 The separate paragraph for 2 would be the exact sentence we now have. 908 A BGP speaker advertises to its peers (other BGP speakers which it 909 communicates with) in neighboring ASs only those routes that it 910 itself uses. 912 In possibility 3 we (try to) clear up the ambiguity about the meaning 913 of the word "use" in this sentence. 915 A BGP speaker advertises to its peers (other BGP speakers which it 916 communicates with) in neighboring ASs only those routes that it 917 itself uses. In this context a BGP speaker is said to "use" a BGP 918 route if it is the most preferred BGP route and is either directly 919 used in forwarding or in a specifically configured case where the BGP 920 route would be forwarded internally but IGP forwarding information is 921 used. The latter case reflects a usage in which the IGP is used for 922 forwarding but BGP is originated to IBGP to carry attributes that 923 cannot be carried by the IGP (for example, BGP communities [N]). 924 Other special cases such as virtual routers and multiple instances of 925 BGP on a single router are beyond the scope of this document but for 926 each of these the statement "a BGP speaker advertises to its peers 927 (other BGP speakers which it communicates with) in neighboring ASs 928 only those routes that it itself uses" can (and should in the 929 definition of the extension) be made true with an appropriate 930 definition of the word "use". 932 Unless someone volunteers better wording this may be a good starting 933 point. I thing the last sentence borders on ridiculous in a protocol 934 spec but may be necessary to address specific objections raised on 935 this mailing list. If we want to elaborate on the meaning of the 936 word "use" and address the objections this is what we end up with. 938 Of course looking at what we ended up with, I'd also go along with 939 the other two options (leave it out or put the one sentence in a 940 separate paragraph as is). 942 After some additional discussion (in the "issue 11.2" thread), we 943 have come to a consensus on this text: 945 In the context of this document we assume that a BGP speaker 946 advertises to its peers only those routes that it itself uses (in 947 this context a BGP speaker is said to "use" a BGP route if it is the 948 most preferred BGP route and is used in forwarding). All other cases 949 are outside the scope of this document. 951 This issue is at consensus. 953 2.11.3 Documenting IBGP Multipath 955 Status: Consensus 956 Change: Yes 957 Summary: The documenting of IBGP Multipath is left to another 958 Internet Draft. The consensus is that it should not be in the base 959 spec. 961 Discussion: 963 This thread began in the "issue 11" discussion. In it it was 964 proposed that: 966 There is support in some router vendors to allow more than one BGP 967 route to be installed, for the purpose for load balancing. Given that 968 this is a current practice, and seems to be a useful feature as well, 969 should we insist that only one route be installed in the Loc-RIB ? 971 I would like to suggest that all sections which use MUST in the 972 context of only one route in Loc-RIB be relaxed a little to a SHOULD, 973 and a section added that states that it is possible for a n 974 implementation to add more than one route to the Loc-RIB for the 975 purposes of load balancing. 977 While it will be useful to describe how this situation is the 978 handler, it is perhaps sufficient to even state that handling of this 979 situation is outside the scope of this RFC. 981 I am including some proposed text for this purpose: 983 For the part: 985 > The Loc-RIB must contain only one route per destination; 987 consider instead, 989 % The Loc-RIB SHOULD contain only one route per destination. % An 990 implementation may choose to install multiple routes to % a 991 destination (for the purposes of load balancing). The % handling of 992 such a configuration, however, is outside the % scope of this RFC. 994 Perhaps, this can be in section 3.2 instead. 996 After much discussion back and forth, it was agreed that documenting 997 IBGP Multipath behavior is a good thing. However, it is something 998 that belongs in another draft. 1000 Alex opened this issue up again. There were a flurry of responses, 1001 most all of them agreeing with the original consensus that we should 1002 document this feature in a different draft, since it doesn't affect 1003 the core interoperability requirements, and we want to advance the 1004 spec in a timely manner. 1006 Alex persisted in his assertion that this belongs in the base 1007 specification. Right now, the issue is still open. 1009 This discussion later expanded in scope to include all BGP multipath. 1011 Curtis laid out a good description of the various flavors of 1012 multipath: 1014 In addition to IGP multihop, there are two cases of BGP multipath. 1016 In IGP multihop there is one BGP advertisement but to ways to reach 1017 th BGP NEXT_HOP via the IGP. 1019 In one case of BGP multihop, two (or more) IBGP routers peering with 1020 the same external AS have equal routes to a destination and are an 1021 equal cost away from a third router. BGP multihop is applicable to 1022 that third router. Without BGP multihop, BGP would normally pick the 1023 BGP NEXT_HOP of the advertisement from only one of those IBGP peers 1024 (using BGP Identifier) and use that. The IGP lookup would yield one 1025 next hop. With BGP multihop, BGP uses the BGP NEXT_HOP of both 1026 advertisements. Each BGP NEXT_HOP has a different IGP next hop (one 1027 or more IGP next hop). 1029 The second case is where all of the candidates routes for BGP 1030 multipath are external. Seldom does IGP multipath come into play for 1031 EBGP (odd tunneled EBGP multihop cases maybe). Typically the load is 1032 split among two (or more) routers in the same AS. 1034 If in EBGP multipath you split among routers in difference AS, an 1035 aggregate should be formed. This is still prior to the IGP cost rule 1036 in the route selection. 1038 Normally one would not combine IBGP and EBGP in multihop given that 1039 the decision point for multihop is after "d" in 9.1.2.2. If the 1040 multihop decision was prior to "d", then two routers each with an 1041 external peering would forward some of the traffic to each other and 1042 for some src/dst pairs, they'd form a loop. [So don't do that!] 1044 This is getting to be a lot to add to the base spec. I hope we've 1045 convinced you that we should put it in another document. 1047 Curtis later added specific text, that could serve as a start for the 1048 new document (or added to the base spec if the consensus ended up 1049 going the other way): 1051 BGP specifies how to select the single best route. OSPF specifically 1052 defines procedures for handling equal cost multipath (ECMP) [cite 1053 OSPF]. The same technique has been applied to ISIS. A similar 1054 technique has been used with BGP. Variations exist but the decision 1055 to support BGP multipath, the specific variation of BGP multipath, or 1056 not to support it, does not affect interoperability. 1058 A naive implementations of ECMP can cause severe performance 1059 degradation for TCP flows. To avoid this, implementations of BGP 1060 multipath SHOULD maintain packet ordering within microflows as 1061 described in [cite rfc2991, rfc2992]. 1063 BGP multipath, if implemented, SHOULD be disabled by default. 1065 In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there 1066 are two variations of BGP multipath described here. A BGP 1067 implementation may offer both, either one, or neither variation of 1068 BGP multipath. Other variations of BGP multipath may exist, but no 1069 guarantees can be made in this protocol specification of their 1070 properties or impact on interoperability. 1072 Where IGP multipath is used, there is an interaction with BGP learned 1073 routes. The lookup of a BGP NEXT_HOP in the IGP can result in the 1074 selection of an IGP multipath entry. This is not a variation of BGP 1075 multipath. When this occurs, one BGP route is selected as the best 1076 but there is more than one way to reach the BGP NEXT_HOP via the IGP. 1078 In one variation of BGP multipath, a set of more than one IBGP 1079 routers peering with the same external AS have equal routes to a 1080 destination and are an equal IGP cost away from a second set of one 1081 or more routers. BGP multipath is applicable to the latter set of 1082 routers. Without BGP multipath, BGP would pick the BGP NEXT_HOP of 1083 the advertisement from only one of those IBGP peers (using BGP 1084 Identifier) and use only that BGP route. With BGP multipath, BGP 1085 uses the BGP NEXT_HOP of more than one of these equal cost 1086 advertisements, yielding more than one BGP NEXT_HOP. Each BGP 1087 NEXT_HOP has a different IGP next hop (one or more IGP next hop if 1088 IGP multipath is in use). 1090 The second case is where all of the candidates routes for BGP 1091 multipath are external and learned by a single BGP peer. Without BGP 1092 multipath this peer would select only one of the BGP routes and 1093 obtain only one BGP NEXT_HOP. With BGP multipath, more than one 1094 equal cost route is selected yielding more than one BGP NEXT_HOP. 1095 Seldom does IGP multipath come into play when looking up an EBGP 1096 NEXT_HOP but could in principle be applicable. 1098 If in EBGP multipath traffic is split among routers in difference AS, 1099 an aggregate SHOULD be formed so as to propagate a route with an 1100 accurate AS_PATH. If the resulting aggregate is not more specific 1101 than the components, the AS_SET SHOULD NOT be dropped. 1103 The decision point for multipath is after step "d" in Section 9.1.2.2 1104 (prefer externally learned routes). IBGP learned and EBGP learned 1105 routes MUST NOT be combined in multipath. If the multipath decision 1106 is prior to "d", then two routers each with an external peering would 1107 form a routing loop. 1109 The decision point for multipath is generally after step "e" in 1110 Section 9.1.2.2. Some relaxation of the "equal cost" rule (also 1111 applicable to IGP multipath) is possible. In addition to the equal 1112 cost BGP NEXT_HOPS available at BGP route selection, if the IGP next 1113 hop for other BGP NEXT_HOPs are of lower cost, then those may be used 1114 as well. This relaxation of the step "e" is possible but is not 1115 widely implemented (and may not be implemented at all). 1117 The consensus of the majority of the IDR WG is to keep this in a 1118 separate draft and out of the base spec. 1120 2.12 TCP Behavior Wording 1122 Status: Consensus 1123 Change: No 1124 Summary: In issue 19 we decided to remove this section entirely. As 1125 a result the previous consensus on this issue (no change) is needed 1126 moot. 1128 Discussion: The subject-less "your mail" thread discussed a wording 1129 clarification from: 1131 "An implementation that would "hang" the routing information process 1132 while trying to read from a peer could set up a message buffer (4096 1133 bytes) per peer and fill it with data as available until a complete 1134 message has been received. " 1136 To something that is more TCP-correct, such as: 1138 "An implementation that would "hang" the routing information process 1139 while trying to received from a peer could set up a message buffer 1140 (4096 bytes) per peer and fill it with data as available until a 1141 complete message has been received. " 1143 (only change: "read" to "received" This was one of a couple of 1144 suggested changes.) 1146 This suggestion was quite contentious, and although there were a 1147 variety of alternate texts proposed, the only consensus was that this 1148 was a very minor issue, and probably not worth changing. 1150 In issue 19 we decided to remove this section entirely. 1152 2.13 Next Hop for Originated Route 1154 Status: Consensus 1155 Change: No 1156 Summary: No responses, assumed consensus to keep things the same. 1158 Discussion: 1160 There was a one-message thread entitled "next hop for originated 1161 route". This message received no response, so the assumption is that 1162 there is a consensus to keep things as they are. 1164 For related discussion see issue 61. 1166 2.14 NEXT_HOP to Internal Peer 1168 Status: Consensus 1169 Change: No 1170 Summary: Closed in favor of issue 61. 1172 Discussion: 1174 The thread entitled "NEXT_HOP to internal peer" starts with this 1175 question: 1177 When sending a locally originated route to an internal peer, what 1178 should NEXT_HOP be set to? 1180 One response suggested that we add a line stating that the NEXT_HOP 1181 address originates from the IGP. 1183 Since this issue and issue 61 are basically the same, except 61 1184 proposes text, we'll close this issue in favor of 61. 1186 2.15 Grammar Fix 1188 Status: Consensus 1189 Change: Yes 1190 Summary: Change: "The Prefix field contains IP address prefixes ..." 1191 To: "contains an IP address prefix ..." 1193 Discussion: The thread entitled "Review comment: bottom of page 16" 1194 corrects a grammar mistake by suggesting we change: 1196 "The Prefix field contains IP address prefixes ..." 1198 to: 1200 "contains an IP address prefix ..." 1202 Yakov responded that this will be fixed in -18. 1204 The consensus seems to be to correct this, and go with the new text. 1206 2.16 Need ToC, Glossary and Index 1208 Status: Consensus 1209 Change: Yes 1210 Summary: Need to add a Table of Contents (ToC), Glossary and Index to 1211 the draft. Will be added in draft -18. 1213 Discussion: 1215 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests: 1217 1. Document needs, Table of Contents, Glossary, and Index 1219 2. Paths, Routes, and Prefixes need to be defined in the spec early 1220 on (like in a glossary), so it is obvious what is implied. 1222 Yakov responded that draft -18 will have a ToC and definition of 1223 commonly used terms. 1225 2.17 Add References to other RFC-status BGP docs to base spec. 1227 Status: Consensus 1228 Change: Yes 1229 Summary: Add references to other RFC-status BGP docs to the base 1230 spec. 1232 Discussion: 1234 The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes 1235 titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to 1236 suggest: 1238 3. All BGP Extensions described in other documents that made it to 1239 RFC status should be at least referenced in the Reference section 1240 P.64. This is justifiable since it's the core BGP standard spec. 1242 Yakov responded that this will be added to the -18 review. 1244 Jonathan agreed. 1246 2.18 IP Layer Fragmentation 1248 Status: Consensus 1249 Change: No 1250 Summary: No need to mention IP Layer Fragmentation in the BGP 1251 specification, since this is taken care of at the TCP level. 1253 Discussion: 1255 1. P.6 section 4. Message Formats, its possible for the source BGP 1256 peer IP layer to fragment a message such that the receiving BGP peer 1257 socket layer would have to reassemble it. Need to mention this, since 1258 BGP implementations are required to do this. 1260 The response to this was that, while true, reassembly is something 1261 that is inherent in the TCP layer that BGP rides over. Therefore, 1262 this is something that is in the TCP spec, and needn't be repeated in 1263 the BGP spec. This comment was reaffirmed. There seems to be 1264 consensus that this isn't something that needs to be in the BGP spec. 1266 2.19 Appendix Section 6.2: Processing Messages on a Stream Protocol 1268 Status: Consensus 1269 Change: Yes 1270 Summary: Remove the section entirely, as this is something that does 1271 not belong in the base spec. 1273 Discussion: 1275 This first came up in response to Issue 17: 1277 There was one comment suggesting that section 6.2 (Processing 1278 Messages on a Stream Protocol" mentioned this. 1280 The original reviewer responded that the out-of-scope comment was 1281 out-of-place and referred the responder to section 6.2 (appendix 6) 1283 The original reviewer stated that he is happy with just adding a 1284 reference to section 6.2 in appendix 6 and leaving it at that. 1286 Curtis suggested we just add a reference to Stevens in appendix 6. 1287 6.2 and be done with it. Specifically: 1289 6.2 Processing Messages on a Stream Protocol 1291 BGP uses TCP as a transport mechanism. If you are unsure as to how 1292 to handle asynchronous reads and writes on TCP sockets please refer 1293 to Unix Network Programming [RWStevens] or other introductory text 1294 for programming techniques for the operating system and TCP 1295 implementation that you are using. 1297 There were further suggestions to remove the section entirely as out- 1298 of-scope. At least 3 people agreed with this. 1300 Alex responded that he sees no reason to remove it, but wouldn't have 1301 a problem if the WG decides to do so. 1303 There seems to be general agreement that this section should be 1304 removed. 1306 N.B. This also affects issue 12. 1308 2.20 Wording fix in Section 4.3 1310 Status: Consensus 1311 Change: Yes 1312 Summary: A small change for clarity in section 4.3 1314 Discussion: 1316 This suggestion grew out of the discussion on Issue 18. 1318 The following change was suggested in section 4.3, second line of the 1319 first paragraph: 1321 s/UPDATE packet/UPDATE message/ 1323 Yakov agreed to this change and updated the draft. 1325 2.21 Authentication Text Update 1327 Status: Consensus 1328 Change: No 1329 Summary: The consensus is that additional references to RFC2385 are 1330 not necessary. 1332 Discussion: 1334 P. 10, "Authentication Data:" section you might want to add this, It 1335 is also possible to use MD5 (RFC2385) at the transport layer to 1336 validate the entire BGP message. 1338 Yakov replied to this: 1340 There is already text that covers this: 1342 "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may 1343 be used in addition to BGP's own authentication mechanisms." 1345 .... 1347 "In addition, BGP supports the ability to authenticate its data 1348 stream by using [RFC2385]." 1349 So, I see no need to add the text proposed above. 1351 Ishi agreed with Yakov. Jonathan disagreed since he thought no one 1352 uses BGP auth. Ishi replied that there are lots of people who do use 1353 it. Jonathan replied with a clarification question: "Who uses *BGP's 1354 own* authentication mechanisms???" Ron Bonica replied that they use 1355 BGP auth. There was some additional discussion over who implements 1356 simple password authentication vs. MD5. 1358 After further discussion, the consensus seems to be that we should 1359 leave the text as it is for the reasons Yakov pointed out. There was 1360 some discussion over opening a new issue to discuss deprecating the 1361 BGP auth mechanism discussed in RFC1771 in favor of the mechanism in 1362 RFC2385. 1364 The issue of Deprecating BGP AUTH is discussed in issue 62. 1366 2.22 Scope of Path Attribute Field 1368 Status: Consensus 1369 Change: Yes 1370 Summary: This is already being covered by text that has been added to 1371 the -18 draft. 1373 Discussion: 1375 P. 12, right after "Path Attributes". The following sentence should 1376 be added to this section to clarify the scope of the Path Attribute 1377 field. "All attributes in the Path Attribute field represent the 1378 characteristics of all the route prefixes defined in the NLRI field 1379 of the message". 1381 Yakov replied to this that: 1383 This will be covered by the following text in 3.1 that will be in the 1384 -18 version (see also issue 54). 1386 Routes are advertised between BGP speakers in UPDATE messages. 1387 Multiple routes that have the same path attributes can be advertised 1388 in a single UPDATE message by including multiple prefixes in the NLRI 1389 field of the UPDATE message. 1391 Therefore there is no need to add the sentence proposed above. 1393 There were no objections to this statement, so this issue has been 1394 moved into consensus. 1396 2.23 Withdrawn and Updated routes in the same UPDATE message 1397 Status: Consensus 1398 Change: No 1399 Summary: For various reasons, not least of which is compatibility 1400 with existing implementations, the decision was made to keep thing 1401 the way they are. 1403 Discussion: 1405 4. P.16, last paragraph in section 4.3 as stated, "An UPDATE message 1406 should not include the same address prefix in the WITHDRAWN ROUTES 1407 and Network Layer Reachability Information fields, however a BGP 1408 speaker MUST be able to process UPDATE messages in this form. A BGP 1409 speaker should treat an UPDATE message of this form as if the 1410 WITHDRAWN ROUTES doesn't contain the address prefix." 1412 This complexity could have been avoided if withdrawn routes and NLRI 1413 prefixes with their attributes were mutually exclusive of each other 1414 and appeared in different update messages. If that was the case, the 1415 priority of which field to process first would have been as simple as 1416 using "first come, first served" message processing approach. 1418 Yakov commented that this would make the case where they are both in 1419 the same message unspecified. 1421 John commented that this is something we don't want to change this 1422 late in the game. Although it was acknowledged that this might be a 1423 good change if we were working from a clean slate. 1425 Ben acceded that this was somewhat wishful thinking on his part. 1427 Curtis's comment seems to coincide with this message, stating: 1429 The existing rules are very clear. 1431 Summarized: 1433 If an UPDATE contains only a withdraw for a prefix, then withdraw 1434 whatever route the peer had previously sent. 1436 If an UPDATE contains the prefix only in the NLRI section, replace 1437 whatever route had previously been advertised by the peer or add a 1438 route if there was no previous route, in both cases adding a route 1439 with the current attributes. 1441 Don't put the same prefix in the same in both the withdraw and NLRI 1442 section of the same update. 1444 If you receive an UPDATE with the same prefix in both the withdraw 1445 and NLRI, ignore the withdraw. [Some older implementations thought 1446 this was a good way to say "delete then add".] 1448 Process UPDATEs from the same peer in the order received. 1450 And goes on to say, that to him, these rules are clear from the 1451 existing text. 1453 Consensus is that while this would be nice, we need to stick with 1454 what we have, and move on. 1456 2.24 Addition or Deletion of Path Attributes 1458 Status: Consensus 1459 Change: Yes 1460 Summary: Add the following to section 3.1: 1462 Changing the attributes of a route is accomplished by advertising a 1463 replacement route. The replacement route carries new (changed) 1464 attributes and has the same NLRI as the original route. 1466 Discussion: 1468 5. P. 20 Its not stated how we delete or modify Path Attributes 1469 associated with NLRI prefixes. 1471 A response to this comment said that this is implicit in the 1472 definition of "route" and the general withdraw/replace behavior and 1473 therefore doesn't need to be repeated. 1475 Ben responded saying that, while there was an assumption, there was 1476 no well defined mechanism, and this leads to ambiguity. 1478 John responded, no need to define everything explicitly, or we'll be 1479 here forever. 1481 Picking this thread up again, Yakov argued: 1483 By *definition* a route is a pair. From that 1484 definition it follows that changing one or more path attributes of a 1485 route means changing a route, which means withdrawing the old route 1486 (route with the old attributes) from service and advertising a new 1487 route (route with the new attributes). Procedures for doing this are 1488 well-defined (see section 3.1), and therefore no new text to cover 1489 this is needed. 1491 Jonathan agreed with this statement, but Ben argued that the text in 1492 section 3 is insufficient the way it is currently written. After 1493 two iterations, Ben and Yakov agreed on this formulation for an 1494 update to section 3.1: 1496 Changing the attributes of a route is accomplished by advertising a 1497 replacement route. The replacement route carries new (changed) 1498 attributes and has the same NLRI as the original route. 1500 Jeff objected somewhat to the wording, since, because of a bgp route 1501 is defined as a pair, changing either part of 1502 that pair, by definition, changes the route. He acknowledged that 1503 this might fall under the category of implementation detail. 1505 Yakov presented the view that he thought we were at consensus with 1506 the text he proposed above. Jonathan agreed. There were no 1507 objections, so this is moved to Consensus. 1509 2.25 NEXT_HOP Semantics 1511 Status: Consensus 1512 Change: No 1513 Summary: After responders pointed out another sentence, this comment 1514 was resolved. Things will stay the way they are. 1516 Discussion: 1518 1. P.28, 2nd to last paragraph. The line that reads, "To be 1519 semantically correct, the IP address in the NEXT_HOP must not be the 1520 IP address of the receiving speaker, and the NEXT_HOP IP address must 1521 either be the sender's IP address (used to establish the BGP 1522 session), or the interface associated with the NEXT_HOP IP address 1523 must share a common subnet with the receiving BGP speaker..." 1525 This is not always true, what if the current ASBR BGP router is 1526 advertising an external AS route (to a IBGP Peer) whose NEXT_HOP IP 1527 address is the IP address of the EBGP peer in the other AS? 1529 A response to this pointed out that right before this is a sentence 1530 stating that this only applied to eBGP links, and only when the peers 1531 are one hop from each other, so a modification is unnecessary. This 1532 response was confirmed with another. 1534 The original reviewer acknowledged this and withdrew the comment. 1536 The consensus is to leave things the way they are. 1538 2.26) Attributes with Multiple Prefixes 1540 Status: Consensus 1541 Change: No 1542 Summary: After some discussion, the consensus is to keep things the 1543 same since the suggested behavior is defined in the message format. 1545 Discussion: 1547 2. P. 29, Section 6.3. Add this rule near the attribute rules. 1548 "Multiple prefixes that require the same attribute type with 1549 different values must never appear in the same update message". 1551 A response to this suggested that this text is unnecessary since this 1552 behavior is ruled out by the way the message format is defined. 1554 The original commenter agrees with the responder. The consensus is 1555 to leave things the way they are. 1557 2.27 Allow All Non-Destructive Messages to Refresh Hold Timer 1559 Status: Consensus 1560 Change: No 1561 Summary: It is agreed that this is a change that exceeds the original 1562 goal of this draft revision. This goal is to document existing 1563 practice in an interoperable way. 1565 Discussion: 1567 3. P. 29, Section 6.5, Please rewrite this sentence from: "If a 1568 system does not receive successive KEEPALIVE and/or UPDATE and/or 1569 NOTIFICATION messages within the period specified in the Hold Time 1570 field of the OPEN message ..." 1572 To This: "If a system does not receive successive KEEPALIVE and/or 1573 UPDATE and/or any other BGP message within the period specified in 1574 the Hold Time field of the OPEN message ..." 1576 There is disagreement on this change. It has been discussed in other 1577 threads. 1579 The original commenter acknowledged that this is something that would 1580 be "adding a new feature" as opposed to the stated goal of 1581 "documenting what exists." He suggested that the ADs decide if we 1582 should open the door for new features or not. 1584 Yakov replied to this that he would suggest we keep things as is, 1585 since the purpose is to document current implementations. 1587 This did not meet with any objections, so this issue has been moved 1588 into consensus. 1590 2.28 BGP Identifier as Variable Quantity 1592 Status: Consensus 1593 Change: No 1594 Summary: The consensus is that changing the BGP Identifier in the 1595 base draft is out-of-scope at this point in the draft evolution. 1597 Discussion: 1599 4. P. 31, section 6.8, Please rewrite this sentence from: "Comparing 1600 BGP Identifiers is done by treating them as (4-octet long) unsigned 1601 integers." 1603 To This: "Comparing BGP Identifiers is done by treating them as large 1604 numbers based on their IP Address type (e.g. IPv4, IPv6, etc.)." 1606 A response to this was that since BGP Identifier is defined in the 1607 base spec as a 4 byte unsigned integer, and not a variable quantity, 1608 the sentence as written is acceptable. This was also confirmed by 1609 another response. 1611 The original commenter was thinking of IPv6, and providing sufficient 1612 space to allow a full v6 address to be used. 1614 Again, responders said that this is out-of-scope for the current 1615 draft. 1617 2.29 State Why Unresolveable Routes Should Be Kept in Adj-RIB-In 1619 Status: Consensus 1620 Change: Yes 1621 Summary: Add: 1623 "in case they become resolvable" after the last sentence on p. 46. 1625 Discussion: 1627 5. P.46, last sentence, "However, corresponding unresolvable routes 1628 SHOULD be kept in the Adj-RIBs-In." It would helpful if the author 1629 states why unresolvable routes should be kept in Adj-RIBs-In? 1631 A response to this stated "In case they become resolvable" 1633 Yakov responded that: 1635 I suggest we add "in case they become resolvable" after the last 1636 sentence on p. 46. 1638 The original commenter stated that: Then the point that the peer will 1639 not refresh the route if we drop them (unless we use Route Refresh) 1640 because they are unreachable should be made. 1642 Yakov also responded that: 1644 This should be clear from the following text in Section 3: 1646 The initial data flow is the portion of the BGP routing table that is 1647 allowed by the export policy, called the Adj-Ribs-Out (see 3.2). 1648 Incremental updates are sent as the routing tables change. BGP does 1649 not require periodic refresh of the routing table. 1651 Jonathan, who was the original commenter, agreed with both the 1652 changed text and the clarity of section 3. 1654 2.30 Mention Other Message Types 1656 Status: Consensus 1657 Change: Yes 1658 Summary: Add a reference to RFC2918 at the end of the type code list. 1660 Discussion: 1662 1. P. 7 Type: Need to add the new message types such as, Capability 1663 Negotiations (RFC2842), Route Refresh, etc. 1665 One response argued that these are out-of-scope of the base document. 1666 One response agreed, but thought that it should be capability and not 1667 message type. The original commenter responded about Message type 1668 from the capability draft. 1670 Sue mentioned this would be added in the second round. 1672 Yakov replied that: 1674 The only new message type that is covered by an RFC (rather than just 1675 an Internet Draft) is the Refresh message. With this in mind how 1676 about replacing the following: 1678 The following type codes are defined: 1680 1 - OPEN 1681 2 - UPDATE 1682 3 - NOTIFICATION 1683 4 - KEEPALIVE 1685 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 1730 Status: Consensus 1731 Change: No 1732 Summary: The consensus is that this was addressed in 32.1, so we can 1733 close this. 1735 Discussion: 1737 3. P. 13, EGP, are there other EGP protocols other than BGP that are 1738 in use? If not, change EGP to BGP. 1740 A response to this suggested that we add a reference to [1] (the EGP 1741 spec) here. 1743 Another response clarified that this refers to EGP-the-protocol and 1744 NOT the class. 1746 Another response disagreed, but suggested that: 1748 IGP = network was explicitly introduced into bgp (network cmd) 1749 INCOMPLETE = network was implicitly introduced into bgp 1750 (redistribute) EGP = other 1752 The original commenter thought that this referred to EGP-the-class of 1753 protocols. And why not use BGP therefore, as the only EGP. 1755 There was some discussion over whether or not we should mention 1756 something that is historical. 1758 Jeff suggested a footnote in the Origin section about EGP. 1760 Curtis suggested that we state that the EGP in ORIGIN is deprecated, 1761 but retain the value to document what it used to mean. 1763 This reviewer thinks a statement about whether this "EGP" origin 1764 refers to the protocol or the class or protocols would be useful. 1766 Yakov replied that an EGP reference will be added (see issue 9). 1768 Yakov also stated that he doesn't see what is wrong with the current 1769 text, and suggested we keep it. This includes leaving out any 1770 reference to the status of the EGP spec. He sees that it is clear 1771 from context that we are talking about "the EGP" [RFC904]. 1773 Jeff noted that this issue has been sufficiently addressed in the 1774 solution to 32.1. This met with agreement. We are at consensus. 1776 2.32.1 EGP ORIGIN Clarification 1778 Status: Consensus 1779 Change: Yes 1780 Summary: Change section 5.1.1 to read: 1782 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1783 shall be generated by the speaker that originates the associated 1784 routing information. Its value SHOULD NOT be changed by any other 1785 speaker." 1787 Consensus to change: 1789 1 EGP - Network Layer Reachability Information 1790 learned via the EGP protocol 1792 to: 1794 1 EGP - Network Layer Reachability Information 1795 learned via the EGP protocol [RFC904] 1797 Discussion: 1799 This discussion is picked up again in the "Review of draft-ietf-idr- 1800 bgp4-17" thread, where specific text is proposed: 1802 Old: 1804 "ORIGIN is a well-known mandatory attribute that defines the 1805 origin of the path information. The data octet can assume 1806 the following values: 1808 Value Meaning 1810 0 IGP - Network Layer Reachability Information 1811 is interior to the originating AS 1813 1 EGP - Network Layer Reachability Information 1814 learned via the EGP protocol 1816 2 INCOMPLETE - Network Layer Reachability 1817 Information learned by some other means" New: 1819 "ORIGIN is a well-known mandatory attribute that defines the 1820 origin of the path information. The data octet can assume 1821 the following values: 1823 Value Meaning 1825 0 IGP - NLRI was explicitly introduced into bgp 1827 1 EGP - this value was administratively 1828 configured to affect policy decisions or NLRI was 1829 learned via the EGP protocol [1] 1830 2 INCOMPLETE - NLRI was implicitly introduced 1831 into bgp" 1833 since: 1) The network command sets the origin to IGP and I remember 1834 seeing somewhere that only static routes should be set to IGP. 2) 1835 The primary use of EGP value is policy 3) EGP seems to still exist, 1836 anyway even if it does not it is not worth re-writing the world. 1838 Also, change: "5.1.1 ORIGIN 1840 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1841 shall be generated by the autonomous system that originates the 1842 associated routing information. It shall be included in the UPDATE 1843 messages of all BGP speakers that choose to propagate this 1844 information to other BGP speakers." 1846 to: "5.1.1 ORIGIN 1848 The value of the ORIGIN attribute shall be set by the speaker that 1849 originates the associated NLRI. Its value shall not be changed 1850 by any other speaker unless the other speaker is administratively 1851 configured to do so to affect policy decisions." 1853 since: 1) It is already defined as well-known mandatory attribute. 1854 2) It may be set differently within the same AS (not saying this is 1855 good). 3) It is commonly used for policy, but by default does not 1856 get changed. 4) Speakers have no choice, it is mandatory. 1858 After much continued discussion on this in the "issue 32.1" thread, 1859 we seem to have come to a consensus that section 5.1.1 should read: 1861 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1862 shall be generated by the speaker that originates the associated 1863 routing information. Its value should not be changed by any other 1864 speaker unless the other speaker is administratively configured to do 1865 so to affect policy decisions." 1867 This text met with a number of agreements, and one disagreement 1868 stating that we shouldn't have the "unless administratively 1869 configured" portion. 1871 After some further discussion, we have this text on the table: 1873 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1874 generated by the BGP speaker that originates the associated BGP 1875 routing information. The attribute shall be included in the UPDATE 1876 messages of all BGP speakers that choose to propagate this 1877 information to other BGP speakers. 1879 Jonathan suggested that we change "propagate this information" to 1880 "forward this route". He also mentioned that he would prefer 1881 something more explicit instead of/in addition to "The attribute 1882 shall be included in the UPDATE messages of all BGP speakers that 1883 choose to propagate this information to other BGP speakers." such as 1884 "other speakers do not change the ORIGIN value." 1886 On the issue of making the EGP ORIGIN type more clear Andrew 1887 proposed: 1889 To me, there seems to be sufficient confusion around the "EGP" 1890 reference to merit some sort of clarification. The simplest 1891 modification would be to change: 1893 1 EGP - Network Layer Reachability Information 1894 learned via the EGP protocol 1896 to: 1898 1 EGP - Network Layer Reachability Information 1899 learned via the EGP protocol [RFC904] 1901 That would clarify that we're talking about the protocol, and not the 1902 class-of-protocols, or EBGP. It would leave unstated that this could 1903 theoretically be used to muck with route selection. I think that is 1904 ok. If operators want to override ORIGIN to affect some hoho magic, 1905 they are welcome to do so, but I don't think it needs to be 1906 documented in the base spec. 1908 This met with a number of agreements. 1910 On the second text section we are working on, Jonathan objected to 1911 the current working text below and suggested an alternate: 1913 CHANGE: 1915 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is 1916 generated by the BGP speaker that originates the associated BGP 1917 routing information. The attribute shall be included in the UPDATE 1918 messages of all BGP speakers that choose to propagate this 1919 information to other BGP speakers." 1921 TO: 1923 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1924 shall be generated by the speaker that originates the associated 1925 routing information. Its value should not be changed by any other 1926 speaker unless the other speaker is administratively configured to do 1927 so to affect policy decisions." 1929 -or- 1931 "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1932 shall be generated by the speaker that originates the associated 1933 routing information. Its value should not be changed by any other 1934 speaker." 1936 Jonathan cited a recent example of someone who was still confused by 1937 this section of the text in -17 (not specifically the working text). 1939 Yakov proposed this as final text: 1941 In 4.3: 1943 a) ORIGIN (Type Code 1): 1945 ORIGIN is a well-known mandatory attribute that defines the origin of 1946 the path information. The data octet can assume the following 1947 values: 1949 Value Meaning 1951 0 IGP - Network Layer Reachability Information 1952 is interior to the originating AS 1954 1 EGP - Network Layer Reachability Information 1955 learned via the EGP protocol [RFC904] 1957 2 INCOMPLETE - Network Layer Reachability 1958 Information learned by some other means 1960 Usage of this attribute is defined in 5.1.1. 1962 In 5.1.1: 1964 ORIGIN is a well-known mandatory attribute. The ORIGIN attribute 1965 shall be generated by the speaker that originates the associated 1966 routing information. Its value SHOULD NOT be changed by any other 1967 speaker." 1969 This met with agreement. This issue is at consensus. 1971 2.32.2 BGP Destination-based Forwarding Paradigm 1972 Status: Consensus 1973 Change: Yes 1974 Summary: After much discussion, this is the consensus: This text in 1975 the current draft: 1977 To characterize the set of policy decisions that can be enforced 1978 using BGP, one must focus on the rule that a BGP speaker advertises 1979 to its peers (other BGP speakers which it communicates with) in 1980 neighboring ASs only those routes that it itself uses. This rule 1981 reflects the "hop-by-hop" routing paradigm generally used throughout 1982 the current Internet. Note that some policies cannot be supported by 1983 the "hop-by-hop" routing paradigm and thus require techniques such as 1984 source routing (aka explicit routing) to enforce. For example, BGP 1985 does not enable one AS to send traffic to a neighboring AS intending 1986 that the traffic take a different route from that taken by traffic 1987 originating in the neighboring AS. On the other hand, BGP can support 1988 any policy conforming to the "hop-by-hop" routing paradigm. Since the 1989 current Internet uses only the "hop-by-hop" inter-AS routing paradigm 1990 and since BGP can support any policy that conforms to that paradigm, 1991 BGP is highly applicable as an inter-AS routing protocol for the 1992 current Internet. 1994 will be replaced in -18 with the following text: 1996 Routing information exchanged via BGP supports only the destination- 1997 based forwarding paradigm, which assumes that a router forwards a 1998 packet based solely on the destination address carried in the IP 1999 header of the packet. This, in turn, reflects the set of policy 2000 decisions that can (and can not) be enforced using BGP. Note that 2001 some policies cannot be supported by the destination-based forwarding 2002 paradigm, and thus require techniques such as source routing (aka 2003 explicit routing) to be enforced*. Such policies can not be enforced 2004 using BGP either. For example, BGP does not enable one AS to send 2005 traffic to a neighboring AS for forwarding to some destination 2006 (reachable through but) beyond that neighboring AS intending that the 2007 traffic take a different route to that taken by the traffic 2008 originating in the neighboring AS (for that same destination). On 2009 the other hand, BGP can support any policy conforming to the 2010 destination-based forwarding paradigm. 2012 Discussion: 2014 In response to these proposals, Yakov proposed that the real problem 2015 is that it is not clear that BGP is build to support the destination- 2016 based forwarding paradigm. To fix this, it was proposed that: 2018 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. 2068 On the other hand, BGP can support any policy conforming to the 2069 destination-based forwarding paradigm. 2071 To which Yakov replied: 2073 Routing information exchanged via BGP supports only the destination- 2074 based forwarding paradigm, which assumes that a router forwards a 2075 packet based solely on the destination address carried in the IP 2076 header of the packet. This, in turn, reflects the set of policy 2077 decisions that can (and can not) be enforces using BGP. Note that 2078 some policies cannot be supported by the destination-based forwarding 2079 paradigm, and thus require techniques such as source routing (aka 2080 explicit routing) to enforce. Such policies can not be enforced using 2081 BGP either. For example, BGP does not enable one AS to send traffic 2082 through a neighboring AS to some destination (which is outside of the 2083 neighboring AS, but is reachable through the neighboring AS) 2084 intending that the traffic take a different route from that taken by 2085 the traffic to the same destination that originating in the 2086 neighboring AS. On the other hand, BGP can support any policy 2087 conforming to the destination-based forwarding paradigm. 2089 And Chris responded: 2091 Routing information exchanged via BGP supports only the destination- 2092 based forwarding paradigm, which assumes that a router forwards a 2093 packet based solely on the destination address carried in the IP 2094 header of the packet. This, in turn, reflects the set of policy 2095 decisions that can (and can not) be enforces using BGP. Note that 2096 some policies cannot be supported by the destination-based forwarding 2097 paradigm, and thus require techniques such as source routing (aka 2098 explicit routing) to enforce. Such policies can not be enforced using 2099 BGP either. For example, BGP does not enable one AS to send traffic 2100 through a neighboring AS to some destination beyond the neighboring 2101 AS intending that the traffic take a different route from that taken 2102 by traffic to the same destination which originates in the 2103 neighboring AS. In other words, the BGP policy of a local AS cannot 2104 affect the downstream (aka, away from the local AS) forwarding policy 2105 of a remote AS. On the other hand, BGP can support any policy 2106 conforming to the destination-based forwarding paradigm. 2108 Tom Petch preferred Yakov's second formulation, with these changes: 2110 policies can not be enforced using BGP either. For example, BGP does 2111 not enable one AS to send traffic ! to a neighboring AS for 2112 forwarding to some destination (reachable through but) beyond ! 2113 that neighboring AS intending that ! the traffic take a different 2114 route to that taken by the traffic ! originating in the 2115 neighboring AS (for that same destination). 2117 On the other hand, BGP can support any policy conforming to the 2118 destination-based forwarding paradigm. 2120 Yakov agreed to Tom's suggested changes. 2122 2.33 Add "Optional Non-Transitive" to the MED Section 2124 Status: Consensus 2125 Change: Yes 2126 Summary: Add "Optional Non-Transitive" to MED Section 2127 Add "well-known mandatory" to the NEXT_HOP Section 2129 Discussion: 2131 4. P.23, change the following: 2133 "The MULTI_EXIT_DISC attribute may be used on external (inter-AS) 2134 links to discriminate among multiple exit or entry points to the same 2135 neighboring AS ..." 2137 To the following: 2139 "The MULTI_EXIT_DISC is an optional non-transitive attribute which 2140 may be used on external (inter-AS) links to discriminate among 2141 multiple exit or entry points to the same neighboring AS ..." 2143 A responder disagreed, and stated reasons "covered elsewhere" 2144 Original commenter asked for reasons, since the modification seemed 2145 obvious to him. 2147 Yakov agreed to make this change in -18. 2149 Jonathan replied that: 2151 5.1.3 NEXT_HOP also, it is missing " well-known mandatory". 2153 Yakov also agreed to make this change. 2155 2.34 Timer & Counter Definition 2157 Status: Consensus 2158 Change: No 2159 Summary: No discussion, no text proposed, defaults to consensus for 2160 no change. 2162 Discussion: 2164 5. In section 8, there are a number of Timers, Counters, etc. that 2165 need to be explicitly defined before they are used by the FSM. 2166 Perhaps these definitions should go in the Glossary section. 2168 There has been no further discussion on this issue. Unless it is 2169 brought up again, this issue is in consensus, with no change. 2171 2.35 Fix Typo 2173 Status: Consensus 2174 Change: Yes 2175 Summary: Fix a Typo. No discussion, but this seem clear. 2177 Discussion: 2179 1. P. 41. Typing error, "Each time time the local system...". 2181 2.36 Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 2183 Status: Consensus 2184 Change: Yes 2185 Summary: This change requires a glossary. Yakov has committed to 2186 having a section where commonly used terms are defined in draft 18, 2187 so this issue is at consensus. 2189 Discussion: 2191 2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in 2192 the glossary, so when they are used in section 9.1, it is well 2193 understood what they are. 2195 Yakov replied: 2197 will be added to the section "Definition of commonly used terms" in 2198 -18 version. 2200 2.37 Combine "Unfeasible Routes" and "Withdrawn Routes" 2202 Status: Consensus 2203 Change: Yes 2204 Summary: Add the following terms to the "commonly used terms 2205 section": 2207 Feasible route A route that is available for use. 2209 Unfeasible route A previously advertised feasible route that is no 2210 longer available for use. 2212 Discussion: 2214 3. P. 45, Phase I, There is no definition of what are unfeasible 2215 routes? Are they the same as withdrawn routes? If so, the two should 2216 be combined to one name. 2218 Ishi replied to this that he thought that we could combine the two 2219 terms, since there is limited difference from an implementation 2220 standpoint. 2222 Yakov replied: 2224 The routes are withdrawn from service because they are unfeasible, 2225 not because they are "withdrawn". So, we need to keep the term 2226 "unfeasible" to indicate the *reason* why a route could be withdrawn. 2227 On the other hand, "withdrawn" is used as a verb, and to the best of 2228 my knowledge "unfeasible" can't be used as a verb. With this in 2229 mind, I don't think that we can combine the two into a single term. 2231 Ishi replied that he was convinced, and that the terms should stay 2232 separate. 2234 Andrew asked the list if we should define these terms in the 2235 "commonly used terms" section in draft -18. 2237 Ben replied that if we use them a lot, we should define them, and if 2238 not local definitions will suffice. 2240 There was some back and forth about the necessity of defining terms 2241 which should be obvious. 2243 mrr actually checked the doc to see if we were consistently using the 2244 terms, and found: 2246 It turns out there there is an inconsistency in the usage of the word 2247 withdrawn. 2249 Section 3.1: 2251 There are three methods by which a given BGP speaker can indicate 2252 that a route has been withdrawn from service: 2254 ... 2256 b) a replacement route with the same NLRI can be advertised, or 2258 ... 2260 Later, in the definition of Withdrawn Routes Length, we have: 2262 A value of 0 indicates that no routes are being withdrawn from 2263 service, 2265 Taken together, this could be construed as meaning that a Withdrawn 2266 Routes Length of 0 indicates that all routes included in the UPDATE 2267 represent newly feasible routes... not replacement routes. 2269 Now, it's possible that this problem has been removed by changes to 2270 the text that have not yet been incorporated in to a new draft; 2271 however, it arose because the text, for the most part, does _not_ use 2272 "withdrawn" in the standard way. Instead, it refers to routes 2273 included in the WITHDRAWN ROUTES field of an UPDATE message. 2274 Consequently, I propose defining a "withdrawn route" as follows: 2276 Withdrawn route: a route included in the WITHDRAW ROUTES field of an 2277 UPDATE message. 2279 Regardless of whether or not this definition is included, Section 3.1 2280 should be changed from: 2282 There are three methods by which a given BGP speaker can indicate 2283 that a route has been withdrawn from service: 2285 to: 2287 There are three methods by which a given BGP speaker can indicate 2288 that a route has been removed from service: 2290 or: 2292 There are three methods by which a given BGP speaker can indicate 2293 that a route is now unfeasible: 2295 After some further off-list discussion, mrr agreed that this 2296 inconsistency is extremely minor, and withdrew his comment. feasible 2297 and unfeasible route will be defined in the "commonly used terms" 2298 section to clear up any confusion. 2300 2.38 Clarify Outbound Route Text 2302 Status: Consensus 2303 Change: No 2304 Summary: Consensus that the issue was sufficiently minor to leave 2305 things alone. 2307 Discussion: 2309 4. P. 50, line, "If a route in Loc-RIB is excluded from a particular 2310 Adj-RIB-Out the previously advertised route in that Adj-RIB-Out must 2311 be withdrawn from service by means of an UPDATE message (see 9.2)." 2313 Would like to rephrase the sentence for clarity, "If a route in Loc- 2314 RIB is excluded from a particular Adj-RIB-Out and was previously 2315 advertised via Adj-RIB-Out, it must be withdrawn from service by 2316 means of an UPDATE message (see 9.2)." 2318 One comment suggested either leave it alone, or remove "via Adj-RIB- 2319 Out". 2321 The original commenter withdrew the comment. 2323 2.39 Redundant Sentence Fragments 2325 Status: Consensus 2326 Change: Yes 2327 Summary: Fix typo & parentheses. 2329 Discussion: 2331 5. P. 50, section 9.1.4, The two fragments of this sentence are 2332 redundant and don't say anything new or simplify the content. Just 2333 keep one fragment. 2335 "A route describing a smaller set of destinations (a longer prefix) 2336 is said to be more specific than a route describing a larger set of 2337 destinations (a shorted prefix); similarly, a route describing a 2338 larger set of destinations (a shorter prefix) is said to be less 2339 specific than a route describing a smaller set of destinations (a 2340 longer prefix)." 2342 There was a comment that disagreed, thinking that both "more 2343 specific" and "less specific" need to be defined. And suggested that 2344 only the third and forth parentheses need to be dropped. 2346 The original commenter agreed with the parentheses changes. 2348 Yakov agreed to drop the third and fourth parentheses in the -18 2349 version. 2351 Jonathan replied to this: 2353 Disagree, the text if fine the way it is, except you need to change 2354 "shorted" to "shorter". 2356 After minimal further discussion, it was decided we are at a 2357 consensus on this issue to fix the typo and drop the third and fourth 2358 parentheses. 2360 2.40 Section 9.2.1.1 - Per Peer vs. Per Router 2361 MinRouteAdvertisementInterval 2363 Status: Consensus 2364 Change: No 2365 Summary: The consensus is that current practice allows for the 2366 MinRouteAdvertisementInterval to be set per peer, so the text should 2367 be kept the same. 2369 Discussion: 2371 6. P. 52, section 9.2.1.1 Change this sentence for clarity, "This 2372 rate limiting procedure applies on a per-destination basis, although 2373 the value of MinRouteAdvertisementInterval is set on a per BGP peer 2374 basis." 2376 To This: "This rate limiting procedure applies on a per-destination 2377 basis, although the value of MinRouteAdvertisementInterval is set on 2378 a BGP router (same value for all peers) basis." 2380 There was a comment disagreeing with this proposal. It was later 2381 elaborated on to include that the reason for disagreement was that 2382 the proposed changes changed the protocol and not just a practice 2383 clarification. Ben responded asking for how this is a protocol 2384 change, he saw it as a clarification. Perhaps there is something 2385 deeper that needs to be clarified? Again, response to this is that 2386 current implementations allow the MinRouteAdvertisementInterval to be 2387 set per-peer, not per-router. 2389 Original reviewer conceded the point. 2391 There was some additional discussion on this point. Most of it was 2392 along the lines of extracting what was really implemented and 2393 supported among various vendors. The conclusion was the same. 2395 2.41 Mention FSM Internal Timers 2397 Status: Consensus 2398 Change: No 2399 Summary: No discussion on this issue. No text proposed. Perhaps 2400 this is in the FSM section of the draft? Either way, it defaults to 2401 consensus with no change. 2403 Discussion: 2405 7. P. 61, item 6.4. Although all the BGP protocol interfacing timers 2406 are mentioned, there are a few FSM internal timers mentioned in the 2407 spec that need to be covered here as well. 2409 There has been no discussion on this, it now defaults to consensus 2410 with no change. 2412 2.42 Delete the FSM Section 2414 Status: Consensus 2415 Change: No 2416 Summary: There was some confusion on the question: Is the FSM draft 2417 going to be a separate document, or incorporated into the base draft. 2418 The consensus is that it is going to become part of the base draft, 2419 so the FSM section will be kept, and elaborated on. 2421 Discussion: 2423 8. Since there is going to be an FSM spec, do we need to have FSM 2424 descriptions in this spec. Maybe the FSM section should be delete. 2426 There was one response agreeing with this. One response asking for 2427 clarification: Was this a move to remove section 8. Finite State 2428 Machine from the base draft?? The original reviewer said, yes, when 2429 Sue's FSM draft becomes a WG document, we should remove section 8 2430 from the base draft. Yakov asked that the AD's provide input on this 2431 suggestion. 2433 Alex responded saying that the FSM draft is going to be part of the 2434 base spec, and not another document once the FSM words are approved. 2436 2.43 Clarify the NOTIFICATION Section 2438 Status: Consensus 2439 Change: Yes 2440 Summary: Replace: 2442 "If a peer sends a NOTIFICATION message, and there is an error in 2443 that message, there is unfortunately no means of reporting this error 2444 via a subsequent NOTIFICATION message." 2446 With: 2448 If a peer sends a NOTIFICATION message, and the receiver of the 2449 message detects an error in that message, the receiver can not use a 2450 NOTIFICATION message to report this error back to the peer. 2452 Discussion: 2454 The "NOTIFICATION message error handling" thread proposed: 2456 Please change" "If a peer sends a NOTIFICATION message, and there is 2457 an error in that message, there is unfortunately no means of 2458 reporting this error via a subsequent NOTIFICATION message." 2460 To: "If a peer receives a NOTIFICATION message, and there is an error 2461 in that message, there is unfortunately no means of reporting this 2462 error via a subsequent NOTIFICATION message." 2464 This reversal of meaning met with disagreement, and this text was 2465 proposed instead: 2467 All errors detected while processing the NOTIFICATION message cannot 2468 be indicated by sending subsequent NOTIFICATION message back to 2469 originating peer, therefore there is no means of reporting 2470 NOTIFICATION message processing errors. Any error, such as an 2471 unrecognized Error Code or Error Subcode, should be noticed, logged 2472 locally, and brought to the attention of the administration of the 2473 peer that has sent the message. The means to do this, however, lies 2474 outside the scope of this document. 2476 The original posted agreed with the intent of the respondent's text, 2477 thought it was too wordy, but did not propose alternate text. 2479 Yakov replied with this proposed text: 2481 If a peer sends a NOTIFICATION message, and the receiver of the 2482 message detects an error in that message, the receiver can not use a 2483 NOTIFICATION message to report this error back to the peer. 2485 Two responses liked this new text. Unless there are objections, 2486 we'll consider that a consensus. 2488 2.44 Section 6.2: OPEN message error handling 2490 Status: Consensus 2491 Change: No 2492 Summary: One commenter observed that the spec seems to specify 2493 behavior that doesn't seem to be observed by extant implementations, 2494 and suggested modifications to the spec. They were later reminded 2495 that the base behavior is acceptable, and agreed. 2497 Discussion: 2499 The "BGP4 draft ; section 6.2" thread began with a discussion of 2500 section 6.2: OPEN message error handling. Specifically: 2502 "If one of the optional parameters in the Open message is not 2503 recognized, then the error subcode is set to 'unsupported optional 2504 parameters" 2506 We have hit on this line when we were testing a BGP connection 2507 between a speaker that supported capability negotiation and a speaker 2508 that did not. 2510 The speaker that did not support the negotiation closed down the 2511 peering session using the error clause mentioned above. Sometimes 2512 this lead to the other router to repeat the OPEN message with the 2513 Capability optional parameter; a game that went on for minutes. 2515 This router manufacturer stated in a reply to this that : "One should 2516 not close down the connection if an optional parameter is 2517 unrecognized. That would make this parameter basically mandatory. 2518 This is an well known error in the BGP spec. Neither Cisco or Juniper 2519 do this" 2521 If this is true it might be good to adapt the text. 2523 The response to this quoted RFC2842, Capabilities Advertisement with 2524 BGP-4: 2526 A BGP speaker determines that its peer doesn't support capabilities 2527 advertisement, if in response to an OPEN message that carries the 2528 Capabilities Optional Parameter, the speaker receives a NOTIFICATION 2529 message with the Error Subcode set to Unsupported Optional Parameter. 2530 In this case the speaker should attempt to re-establish a BGP 2531 connection with the peer without sending to the peer the Capabilities 2532 Optional Parameter. 2534 The original poster responded: 2536 This section from the Capabilities Advertisement RFC, is indeed 2537 inline with the section 6.2 of the BGP4 specification. For me however 2538 the question remains if most implementations do no simply ignore 2539 optional parameters that are unknown. And if so, if the text stated 2540 above reflects what is implemented by routers that do not have 2541 capability advertisement at all. 2543 Yakov replied to this with: 2545 RFC2842 assumes that a router (that doesn't implement RFC2842) would 2546 close the BGP session when the router receives an OPEN message with 2547 an unrecognized Optional Parameter. Therefore the text in the spec 2548 should be left unmodified. 2550 The original poster, Jonathan, agreed with this. This issue moves to 2551 consensus. 2553 2.45 Consistent References to BGP Peers/Connections/Sessions 2555 Status: Consensus 2556 Change: Yes 2557 Summary: Stick with "BGP Connection" as the consistent term. 2559 Discussion: 2561 Ben proposed and Yakov responded: 2563 > 1. Throughout the document we have various ways of naming the BGP > 2564 peering communication. 1) BGP Session, 2) BGP Peering Session, 2566 I'll replace "session" with "connection". 2568 > 3) TCP Connection, 2570 The spec doesn't name BGP peering communication as "TCP connection"; 2571 TCP connection is used to establish BGP connection. So, TCP 2572 connection and BGP connection are two different things. 2574 > 4) BGP Connection, 2576 The spec is going to use this term (see above). 2578 > 5) BGP Peering Connection, 2580 I'll replace "BGP peering connection" with "BGP connection". 2582 > 6) Connection, 2584 The text uses "connection" whenever it is clear from the context that 2585 it refers to "BGP connection" (or "TCP connection"). 2587 > 7) BGP Speaker Connection. 2589 I'll replace "BGP Speaker Connection" with "BGP connection". 2591 > > BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker 2593 The term "speaker" is used when it is clear from the context that we 2594 are talking about "BGP speaker". 2596 > 2. Change Internal peer to IBGP Peer. 2598 IBGP stands for "BGP connection between internal peers". Therefore 2599 the term "IBGP Peer" would mean "BGP connection between internal 2600 peers peer". That doesn't seem appropriate. 2602 This issue has had some discussion, and section 3 was referenced, 2603 specifically: 2605 Refer to Section 3 - Summary of operations which clearly states that 2606 " .. a peer in a different AS is referred to as an external peer, 2607 while a peer in the same AS may be described as an internal peer. 2608 Internal BGP and external BGP are commonly abbreviated IBGP and EBGP" 2610 After more discussion it was decided that we should modify a 2611 paragraph on page 4 to read: 2613 If a particular AS has multiple BGP speakers and is providing transit 2614 service for other ASs, then care must be taken to ensure a consistent 2615 view of routing within the AS. A consistent view of the interior 2616 routes of the AS is provided by the IGP used within the AS. For the 2617 purpose of this document, it is assumed that a consistent view of the 2618 routes exterior to the AS is provided by having all BGP speakers 2619 within the AS maintain IBGP with each other. Care must be taken to 2620 ensure that the interior routers have all been updated with transit 2621 information before the BGP speakers announce to other ASs that 2622 transit service is being provided. 2624 This change has consensus. 2626 > 3. Change External peer to EBGP Peer. 2628 Ditto. 2630 Alex responded that having explicit definitions would be nice. This 2631 ties into the general glossary suggestion (see issues 16, 34 & 36). 2633 He also suggested that: 2635 "BGP session" which works over a "TCP connection" would be closer to 2636 the terminology we're actually using now and would avoid possible 2637 confusions when people read terms like "Connection collision") 2639 This was discussed in the "Generial Editorial Comment" thread. 2641 After some further discussion, it was decided that, due to existing 2642 implementations, we should go with "BGP connection" as the consistent 2643 term. We are at consensus. 2645 2.46 FSM Connection Collision Detection 2646 Status: Consensus 2647 Change: Yes 2648 Summary: Add this to section 8: 2650 There is one FSM per connection. Prior to determining what peer a 2651 connection is associated with there may be two connections for a 2652 given peer. There should be no more than one connection per peer. 2653 The collision detection identifies the case where there is more than 2654 one connection per peer and provides guidance for which connection to 2655 get rid of. When this occurs, the corresponding FSM for the 2656 connection that is closed should be disposed of. 2658 Discussion: 2660 The original reviewer (Tom) commented that the base draft, FSM 2661 section, could use some clarification around the area of connection 2662 collision detection. Specifically, he argued that it seems like 2663 there are actually 2 FSM's depending on which one backs off in the 2664 case of a collision. He proposed this text to clear things up: 2666 "8 BGP Finite State Machine 2668 This section specifies BGP operation - between a BGP speaker and its 2669 peer over a single TCP connection - in terms of a Finite State 2670 Machine (FSM). Following is a brief summary ... "(as before) 2672 Instead of just 2674 "This section specifies BGP operation in terms of a Finite State 2675 Machine (FSM). Following is a brief summary ... "(as before). 2677 Curtis responded: 2679 There is one FSM per connection. Prior to determining what peer a 2680 connection is associated with there may be two connections for a 2681 given peer. There should be no more than one connection per peer. 2682 The collision detection identifies the case where there is more than 2683 one connection per peer and provides guidance for which connection to 2684 get rid of. When this occurs, the corresponding FSM for the 2685 connection that is closed should be disposed of. 2687 I'm not sure which document containing an FSM we should be reading at 2688 this point, but we could add the above paragraph if we need to 2689 explicitly state that the extra connection and its FSM is disposed of 2690 when a collision is detected. 2692 When a TCP accept occurs, a connection is created and an FSM is 2693 created. Prior to the point where the peer associated with the 2694 connection is known the FSM cannot be associated with a peer. The 2695 collision is a transient condition in which the rule of "one BGP 2696 session per peer" is temporarily violated and then corrected. 2698 This is discussed in the "FSM but FSM of what?" thread. 2700 Sue responded that she would be happy to add Curtis' text to section 2701 8 and solicited any additional comments. There was only one on 2702 capitalization, so this issue is at consensus. 2704 2.47 FSM - Add Explicit State Change Wording 2706 Status: Consensus 2707 Change: No 2708 Summary: A desire for explicit state change wording was expressed. 2709 No text was proposed. The assumption is that this issue has reached 2710 a happy conclusion. 2712 Discussion: 2714 The initial reviewer: 2716 In most places, the actions taken on the receipt of an event include 2717 what the new state will be or that it remains unchanged. But there 2718 are a significant number of places where this is not done (eg Connect 2719 state events 14, 15, 16). I would like to see consistency, always 2720 specify the new/unchanged state. Else I may be misreading it. 2722 There was a response asking for specific text, and offering to take 2723 the discussion private. 2725 This is discussed in the "FSM words - state changes" thread. 2727 There has been no further discussion on this. The assumption is that 2728 is has reached a happy conclusion privately. 2730 2.48 Explicitly Define Processing of Incoming Connections 2732 Status: Consensus 2733 Change: Yes 2734 Summary: Add text that is at the end of the discussion to section 8. 2736 Discussion: 2738 Alex suggested we explicitly define: 2740 - processing of incoming TCP connections (peer lookup, acceptance, 2741 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. 2791 There exists a period in which the identity of the peer on the other 2792 end of an incoming connection is known but the BGP identifier is not 2793 known. During this time, both an incoming and outgoing connection 2794 for the same configured peering may exist. This is referred to as a 2795 connection collision (see Section x.x, was 6.8). 2797 The next paragraph then needs to get fixed. Changed "for each peer" 2798 to "for each configured peering". 2800 A BGP implementation will have at most one FSM for each configured 2801 peering plus one FSM for each incoming TCP connection for which the 2802 peer has not yet been identified. Each FSM corresponds to exactly 2803 one TCP connection. 2805 Add a paragraph to further clarify the point you made. 2807 There may be more than one connection between a pair of peers if the 2808 connections are configured to use a different pair of IP addresses. 2809 This is referred to as multiple "configured peerings" to the same 2810 peer. 2812 > So multiple simultaneous BGP connection are allowed between the 2813 same two > peers, and this behavior is implemented, for example to do 2814 load balancing. 2816 Good point. 2818 I hope the corrections above cover your (entirely valid) objections. 2819 If you see any more errors please let me know. 2821 Tom replied that: 2823 I take issue with the 'will attempt to connect' which goes too far. 2825 The FSM defines events 4 and 5, 'with passive Transport 2826 establishment', so the system may wait and not attempt to connect. 2827 The exit from this state is either the receipt of an incoming TCP 2828 connection (SYN) or timer expiry. 2830 So we may have a FSM attempting to transport connect for a given 2831 source/destination IP pair or we may have an FSM not attempting to 2832 connect. (In the latter case, I do not think we can get a 2833 collision). In the latter case, an incoming connection should not 2834 generate an additional FSM. 2836 I do not believe the concept of active and passive is helpful since a 2837 given system can flip from one to the other and it does not help us 2838 to clarify the number of FSM involved.. 2840 And Curtis suggested that: 2842 Could this be corrected by replacing "will attempt to connect" with 2843 "unless configured to remain in the idle state, or configured to 2844 remain passive, will attempt to connect". We could also shorten that 2845 to "will attempt to connect unless configured otherwise". 2847 Clarification (perhaps an item for a glossary entry): 2849 The terms active and passive have been in our vocabulary for almost a 2850 decade and have proven useful. The words active and passive have 2851 slightly different meanings applied to a TCP connection or applied to 2852 a peer. There is only one active side and one passive side to any 2853 one TCP connection as per the definition below. When a BGP speaker 2854 is configured passive it will never attempt to connect. If a BGP 2855 speaker is configured active it may end up on either the active or 2856 passive side of the connection that eventually gets established. 2857 Once the TCP connection is completed, it doesn't matter which end was 2858 active and which end was passive and the only difference is which 2859 side of the TCP connection has port number 179. 2861 Tom agreed with Curtis, that he liked the "will attempt to connect 2862 unless configured otherwise" verbiage. 2864 This was discussed in the "Generial Editorial Comment" thread. 2866 Sue proposed we add the text above in section 8.2. It is summarized 2867 here for clarity: 2869 8.2) Description of FSM 2871 8.2.1) FSM connections 2873 (text below) 2875 8.2.2) FSM Definition 2877 (text now in 8.2) 2879 "BGP must maintain a separate FSM for each configured peer plus Each 2880 BGP peer paired in a potential connection unless configured to remain 2881 in the idle state, or configured to remain passive, will attempt to 2882 to connect to the other. For the purpose of 2883 this discussion, the active or connect side of the TCP 2884 connection (the side of a TCP connection (the side sending 2885 the first TCP SYN packet) is called outgoing. The passive or 2886 listening side (the sender of the first SYN ACK) is called 2887 an incoming connection. [See section on the terms active and passive 2889 below.] 2891 A BGP implementation must connect to and listen on TCP port 179 for 2892 incoming connections in addition to trying to connect to peers. Fro 2893 each incoming connection, a state machine must be instantiated. 2894 There exists a period in which the identity of the peer on the other 2895 end of an incoming connection is known but the BGP identifier is not 2896 known. During this time, both an incoming and an outgoing connection 2897 for the same configured peering may exist. This is referred to as a 2898 connection collision (see Section x.x, was 6.8). 2900 A BGP implementation will have at most one FSM for each configured 2901 peering plus one FSM for each incoming TCP connection for which the 2902 peer has not yet been identified. Each FSM corresponds to exactly one 2903 TCP connection. 2905 There may be more than one connections between a pair of peers if the 2906 connections are configured to use a different pair of IP addresses. 2907 This is referred to as multiple "configured peerings" to the same 2908 peer. 2910 8.2.1.1) Terms "active" and "passive" 2912 The terms active and passive have been in our vocabulary for almost a 2913 decade and have proven useful. The words active and passive have 2914 slightly different meanings applied to a TCP connection or applied to 2915 a peer. There is only one active side and one passive side to any 2916 one TCP connection per the definition above [and the state machine 2917 below.] When a BGP speaker is configured active it may end up on 2918 either the active or passive side of the connection that eventually 2919 gets established. Once the TCP connection is completed, it doesn't 2920 matter which end was active and which end was passive and the only 2921 difference is which side of the TCP connection has port number 179. 2923 For additional text, see issue 46. 2925 Sue solicited additional comments, the only one was on 2926 capitalization, so it would appear we are at consensus with this 2927 issue. 2929 2.49 Explicitly Define Event Generation 2931 Status: Consensus 2932 Change: No 2933 Summary: Suggested that we explicitly define BGP message processing. 2934 No text proposed. There has been no further discussion on this 2935 issue, it is assumed that the consensus is that things are ok the way 2936 they are. 2938 Discussion: 2940 Alex suggested we explicitly define: 2942 - generation of events while processing BGP messages, i.e., the text 2943 describing message processing should say where needed that a specific 2944 event for the BGP session should be generated. 2946 No text was proposed. 2948 This discussion has received no further comment. Unless someone 2949 wants to reopen it, it is assumed it has reached a happy ending. 2951 This was discussed in the "Generial Editorial Comment" thread. 2953 2.50 FSM Timers 2955 Status: Consensus 2956 Change: No 2957 Summary: Discussion tabled, because new document version rendered the 2958 discussion moot. 2960 Discussion: 2962 This discussion began with a suggestion that the timers currently in 2963 the FSM: 2965 In the 26 Aug text, I find the timer terminology still confusing. 2966 Timers can, I find, stop start restart clear set reset expire 2968 Can be cleaned up and simplified to: 2970 start with initial value (spell it out just to be sure) stop expire 2972 A response to this proposal was, that the existing set is clear, and 2973 that the proposed set is insufficiently rich to describe a concept 2974 like "reset" which encompasses: "Stop the timer, and reset it to its 2975 initial value." 2977 This discussion reached an impasse, when Sue pointed out that the 2978 text had been updated, and to please review the new text. 2980 This was discussed in the "FSM more words" thread. 2982 2.51 FSM ConnectRetryCnt 2984 Status: Consensus 2985 Change: No 2986 Summary: Discussion tabled, because new document version rendered the 2987 discussion moot. 2989 Discussion: 2991 This started with the observation that the ConnectRetryCnt "seems to 2992 have lost its purpose." It was suggested that this be made a Session 2993 Attribute, along with: OpenDelayTimer and DelayOpenFlag. 2995 Curtis explained that the current purpose of the ConnectRetryCnt is 2996 something to be read by the MIB. He also advocated against adding 2997 the additional Session Attributes. 2999 2.52 Section 3: Keeping routes in Adj-RIB-In 3001 Status: Consensus 3002 Change: Yes 3003 Summary: Add: To allow local policy changes to have the correct 3004 effect without resetting any BGP connections, a BGP speaker SHOULD 3005 either (a) retain the current version of the routes advertised to it 3006 by all of its peers for the duration of the connection, or (b) make 3007 use of the Route Refresh extension [12]. 3009 Discussion: 3011 This thread started with a question about why we should retain routes 3012 in the Adj-RIB-In, and how it relates to the Route Refresh extension. 3014 mrr proposed this text: 3016 ... Therefore, a BGP speaker must either retain the current version 3017 of the routes advertised by all of its peers for the duration of the 3018 connection, or make use of the Route Refresh extension [12]. This is 3019 necessary to allow local policy changes to have the correct effect 3020 without requiring the reset of any peering sessions. 3022 If the implementation decides not to retain the current version of 3023 the routes that have been received from a peer, then Route Refresh 3024 messages should be sent whenever there is a change to local policy. 3026 Yakov later suggested this text, with a slight rewording: 3028 To allow local policy changes to have the correct effect without 3029 resetting any BGP connections, a BGP speaker SHOULD either (a) 3030 retain the current version of the routes advertised to it by all of 3031 its peers for the duration of the connection, or (b) make use of the 3032 Route Refresh extension [12]. 3034 mrr responded that he was fine with Yakov's suggestions. 3036 This was discussed in the "Proxy: comments on section 3" thread. 3038 2.53 Section 4.3 - Routes v. Destinations - Advertise 3040 Status: Consensus 3041 Change: No 3042 Summary: The text that has reached consensus in issue 54 also 3043 addresses this issue. 3045 Discussion: 3047 This issue arose out of this question to the list: 3049 Since: 3051 "For the purpose of this protocol, a route is defined as a unit of 3052 information that pairs a set of destinations with the attributes of a 3053 path to those destinations. The set of destinations are the systems 3054 whose IP addresses are reported in the Network Layer Reachability 3055 Information (NLRI) field and the path is the information reported in 3056 the path attributes field of the same UPDATE message." 3058 When I read section 4.3: 3060 "An UPDATE message is used to advertise feasible routes sharing 3061 common path attribute to a peer, or to withdraw multiple unfeasible 3062 routes from service (see 3.1)." 3064 Shouldn't the text read "... advertise feasible [prefixes | 3065 destinations] sharing common path attribute(S)to a peer ...", 3066 because: 3068 1) A route is defined as quoted above from section 3.1? 3070 or since ... 3072 "An UPDATE message can advertise at most one set of path attributes, 3073 but multiple destinations ..." 3075 2) make "routes" in the original singular. 3077 This was discussed in the "Review Comments: Section 4.3: "routes" vs. 3078 destinations - advertise" thread. 3080 The text that has reached consensus in issue 54 also addresses this 3081 issue. 3083 2.54 Section 4.3 - Routes v. Destinations - Withdraw 3085 Status: Consensus 3086 Change: Yes 3087 Summary: Change the definition of "route" as it currently stands to: 3089 For the purpose of this protocol, a route is defined as a unit of 3090 information that pairs a set of destinations with the attributes of a 3091 path to those destinations. The set of destinations are systems whose 3092 IP addresses are contained in one IP address prefix carried in the 3093 Network Layer Reachability Information (NLRI) field of an UPDATE 3094 message and the path is the information reported in the path 3095 attributes field of the same UPDATE message. 3097 Multiple routes that have the same path attributes can be advertised 3098 in a single UPDATE message by including multiple prefixes in the NLRI 3099 field of the UPDATE message. 3101 Discussion: 3103 This issue was brought up with this question: 3105 When I read these two paragraphs at the end of section 4.3: 3107 "An UPDATE message can list multiple routes to be withdrawn from 3108 service. Each such route is identified by its destination (expressed 3109 as an IP prefix), which unambiguously identifies the route in the 3110 context of the BGP speaker - BGP speaker connection to which it has 3111 been previously advertised. 3113 An UPDATE message might advertise only routes to be withdrawn from 3114 service, in which case it will not include path attributes or Network 3115 Layer Reachability Information. Conversely, it may advertise only a 3116 feasible route, in which case the WITHDRAWN ROUTES field need not be 3117 present." 3119 It reads as if one must withdraw the _set of destinations_ advertised 3120 with the route instead of just one or more destinations since route 3121 is defined in section 3.1 as: 3123 "For the purpose of this protocol, a route is defined as a unit of 3124 information that pairs a set of destinations with the attributes of a 3125 path to those destinations. The set of destinations are the systems 3126 whose IP addresses are reported in the Network Layer Reachability 3127 Information (NLRI) field and the path is the information reported in 3128 the path attributes field of the same UPDATE message." 3130 Shouldn't the text change "routes" to destinations, or to prefixes? 3131 The original commenter added this clarification later: 3133 I meant to say, the *same* set of destinations as those advertised 3134 initially. For example, NLRI with dest-a, dest-b and dest-c with the 3135 same attributes is a "route". The withdrawal of the "route" can be 3136 read as one must withdraw all destinations originally advertised for 3137 that route (dest-a, dest-b, dest-c) as a unit. 3139 A first time reader could be left wondering if the above must be the 3140 case, or it is valid for an implementation to withdraw just one of 3141 these destinations (e.g. dest-b), leaving the others (dest-a, dest-c) 3142 reachable with their attributes intact. 3144 If there is no relationship between destinations when advertised as a 3145 set of destinations in a route and those destinations that can be 3146 withdrawn should be explicitly stated. Otherwise, the draft should 3147 call out that it is not legal to withdraw one prefix only in the set 3148 of prefixes advertised as previously as route. 3150 Matt suggested that since the definition seems to cause some 3151 confusion, that we update the definition to: 3153 "For the purpose of this protocol, a route is defined as a unit of 3154 information that pairs a set of destinations with the attributes of a 3155 path to those destinations. The set of destinations are systems 3156 whose IP addresses are reported in one prefix present in the Network 3157 Layer Reachability Information (NLRI) field of an UPDATE and the path 3158 is the information reported in the path attributes field of the same 3159 UPDATE message. 3161 This definition allows multiple routes to be advertised in a single 3162 UPDATE message by including multiple prefixes in the NLRI field of 3163 the UPDATE. All such prefixes must be associated with the same set 3164 of path attributes." 3166 Yakov suggested some minor rewording: 3168 For the purpose of this protocol, a route is defined as a unit of 3169 information that pairs a set of destinations with the attributes of a 3170 path to those destinations. The set of destinations are systems whose 3171 IP addresses are contained in one IP address prefix carried in the 3172 Network Layer Reachability Information (NLRI) field of an UPDATE 3173 message and the path is the information reported in the path 3174 attributes field of the same UPDATE message. 3176 Multiple routes that have the same path attributes can be advertised 3177 in a single UPDATE message by including multiple prefixes in the NLRI 3178 field of the UPDATE message. 3180 Both Jeff and Matt responded that they liked this text. 3182 2.55) Section 4.3 - Description of AS_PATH length 3184 Status: Consensus 3185 Change: Yes 3186 Summary: Replace: 3188 Path segment length is a 1-octet long field containing the number of 3189 ASs in the path segment value field. 3191 With: 3193 Path segment length is a 1-octet long field containing the number of 3194 ASs (not the number of octets) in the path segment value field. 3196 Discussion: 3198 This question was raised: 3200 Length fields elsewhere in the draft specify the number of bytes that 3201 a variable length field uses. For AS_PATH, length is used as the 3202 number of 2 byte AS numbers. In the interest of not having to check 3203 other sources to be sure, should the description of path segment 3204 value: 3206 "The path segment value field contains one or more AS numbers, each 3207 encoded as a 2-octets long field." 3209 explicitly mention the number of bytes used by the variable length 3210 field? 3212 Or, make the description of length explicitly mention that it is not 3213 the length of the variable length field as is the case with other 3214 length fields? 3216 One response to this agreed that some more clarification would be 3217 good, specifically an ASCII art diagram. No diagram was proposed. 3219 Yakov proposed this change: 3221 How about replacing 3223 Path segment length is a 1-octet long field containing the number of 3224 ASs in the path segment value field. 3226 with the following 3227 Path segment length is a 1-octet long field containing the number of 3228 ASs (but not the number of octets) in the path segment value field. 3230 Jonathan offered this text: 3232 How about: "Path segment length is a 1-octet long field containing 3233 the number of ASs (which is half the number of octets since each AS 3234 is 2 octets) in the path segment value field (also note that the path 3235 may contain more than 1 segment). 3237 Jeff replied that he preferred Yakov's text, but without the "but". 3238 Yakov agreed to that. Andrew also agreed, and asked if there were 3239 any objections to moving this issue into consensus. There were no 3240 objections. 3242 2.56 Section 6 - BGP Error Handling 3244 Status: Consensus 3245 Change: Yes 3246 Summary: There are a variety of updates to the text that are best 3247 described in the discussion section. 3249 Discussion: 3251 This discussion began with some suggestions on ways to clarify the 3252 text in section 6 dealing with error handling. The original 3253 comments, and Yakov's response are below: 3255 > At the beginning of Section 6. BGP Error Handling: 3256 > 3257 > 3258 > "When any of the conditions described here are detected, a 3259 > NOTIFICATION message with the indicated Error Code, Error 3260 Subcode, 3261 > and Data fields is sent, and the BGP connection is closed." 3262 > 3263 > There are several cases where the conditions described in this 3264 section 3265 > do not result in the BGP connection being closed. These conditions 3266 > should either state that the connection stays up. Another 3267 possibility 3268 > is to remove "and the BGP connection is closed." above, and for 3269 each 3270 > listed connection, state what happens to the BGP connection. This 3271 > already takes place for certain conditions, but isn't done 3272 consistently. 3274 How about replacing the above with the following: 3276 When any of the conditions described here are detected, a 3277 NOTIFICATION message with the indicated Error Code, Error Subcode, 3278 and Data fields is sent, and the BGP connection is closed, unless it 3279 is explicitly stated that no NOTIFICATION message is to be sent and 3280 the BGP connection is not to be close. 3282 > I tried to list what I found (which may be wrong or incomplete) 3283 below: 3284 > 3285 > 3286 > "If the NEXT_HOP attribute is semantically incorrect, the error 3287 should 3288 > be logged, and the route should be ignored. In this case, no 3289 > NOTIFICATION message should be sent." 3290 > 3291 > * Append the connection is not closed. 3293 Done. 3295 > 3296 > "(a) discard new address prefixes from the neighbor, or (b) 3297 terminate 3298 > the BGP peering with the neighbor." 3299 > 3300 > * Append "the connection is not closed" to case (a) 3302 added "(while maintaining BGP peering with the neighbor)" to case 3303 (a). 3305 > 3306 > "If the autonomous system number appears in the AS path the 3307 > route may be stored in the Adj-RIB-In," 3308 > 3309 > * append and the BGP connection stays up. 3310 > 3311 > "but unless the router is configured to accept routes with its 3312 > own autonomous system in the AS path, the route shall not be 3313 > passed to the BGP Decision Process." 3315 I would suggest to move this text to Section 9 (UPDATE message 3316 handling), as receiving a route with your own AS in the AS path isn't 3317 really an error. It is just that usually (but not always) you can't 3318 put this route in your Adj-RIB-In. 3320 > * Q1) does the BGP connection stay up? 3322 yes. 3324 > * Q2) what if the router isn't configured to accept routes with its 3325 > own AS in the AS path? One _may_ store the route in Adj-RIB-In, 3326 but 3327 > if one doesn't want to? 3329 So, don't store them. 3331 > Is the BGP connection closed? If so, what subcode? 3333 The connection is *not* closed. 3335 > "If an optional attribute is recognized, then the value of this 3336 > attribute is checked. If an error is detected, the attribute is 3337 > discarded, and the Error Subcode is set to Optional Attribute 3338 Error. 3339 > The Data field contains the attribute (type, length and 3340 value)." 3341 > 3342 > * Append and the BGP connection stays up after "the attribute is 3343 discarded". 3345 Since you have to close the connection, you have to discard all the 3346 routes received via this connection, including the route with the 3347 incorrect attribute. So, there is no need to say that "the attribute 3348 is discarded". 3350 There have been no objections to the updates listed above. This 3351 issue seems to have reached a happy ending, so it has been moved into 3352 consensus. 3354 This was discussed in the "-17 review Section 6 - BGP Error 3355 Handling." thread. 3357 2.57 Section 6.2 - Hold timer as Zero 3359 Status: Consensus 3360 Change: No 3361 Summary: It was suggested that we update the text to say that we MUST 3362 reject hold time values of zero. It was pointed out that this is not 3363 the case and the text should say the way it is. 3365 Discussion: 3367 In Section 6.2 on OPEN message error handling: 3369 If the Hold Time field of the OPEN message is unacceptable, then the 3370 Error Subcode MUST be set to Unacceptable Hold Time. An 3371 implementation MUST reject Hold Time values of one or two seconds. 3373 I feel that text similar to: 3375 "An implementation MUST also reject Hold Time values of zero received 3376 from a peer in a different AS" should be considered for completeness. 3378 A number of respondents pointed out that zero hold time is legitimate 3379 under certain circumstances. 3381 This was discussed in the "-17 review, Section 6.2 - must reject hold 3382 time" thread. 3384 2.58 Deprecation of ATOMIC_AGGREGATE 3386 Status: Consensus 3387 Change: Yes 3388 Summary: For new text, please see the end of the discussion. 3390 Discussion: 3392 Jeff opened this discussion with: 3394 Deprecation of ATOMIC_AGGREGATE: 3396 [This is a summary of some discussions from those who have "been 3397 there, done that" during the CIDR deployment period and also comments 3398 from network operators on the NANOG list.] 3400 When BGP-4 was originally drafted, the topic of aggregation was new 3401 enough that people didn't exactly know how it would be used. 3402 Additionally, there were some transition issues when aggregated 3403 networks would need to be de-aggregated and re-advertised into a 3404 classful routing mesh such as BGP-3. 3406 The ATOMIC_AGGREGATE flag was intended to prevent a route from being 3407 de-aggregated when de-aggregation would introduce routing loops. 3408 Note that de-aggregation in this context specifically means making a 3409 less specific route into one or more more-specific routes. 3411 The current BGP draft has two situations where ATOMIC_AGGREGATE 3412 should be appended to a route: 1. When a route's AS_PATH is 3413 intentionally truncated, such as what happens by default on Cisco's, 3414 or using the "brief" option on GateD. Juniper has a similar feature 3415 - I'm unsure of the default. 2. When two routes are implicitly 3416 aggregated in the LocRib such that a more specific route is not 3417 selected when a less specific route is from a given peer. 3419 Note that this particular feature is not implemented anywhere that I 3420 am aware of. 3422 3. There is a third case not covered by the specification: Implicit 3423 aggregation on export - a more specific route is not exported and 3424 only a less specific one is. 3426 When network operators were asked about de-aggregation practices, I 3427 received about 40 responses. The majority of these responses 3428 confused de-aggregation with leaking existing more-specific routes 3429 that are used internally rather than explicitly de-aggregating a 3430 less-specific route. 3432 There were a very few cases of explicit de-aggregation. One form was 3433 done for purposes of dealing with another ISP creating a routing DoS 3434 by advertising IP space that didn't belong to them - leaked more 3435 specifics alleviated the problem in many cases. (Note that this is a 3436 security issue in the routing system.) 3438 The second case was de-aggregating routes internally (and sending the 3439 routes via IBGP marked with NO-ADVERTISE) for purposes of traffic 3440 engineering routing internally where a given upstream failed to 3441 provide enough routing information to allow traffic flows to be 3442 optimized based on supplied prefixes. 3444 My conclusions to this are: 1. De-aggregation is not a common 3445 practice. 2. It is no longer a major concern since classful inter- 3446 domain routing is pretty much gone. 3. The spec doesn't match 3447 reality and should be corrected. 3449 My suggestions are thus this: Section 5.1.6 should be updated as 3450 follows: ATOMIC_AGGREGATE is a well-known discretionary attribute. 3451 Its use is deprecated. 3453 When a router explicitly aggregates several routes for the purpose of 3454 advertisement to a particular peer, and the AS_PATH of the aggregated 3455 route excludes at least some of the AS numbers present in the AS_PATH 3456 of the routes that are aggregated (usually due to truncation), the 3457 aggregated route, when advertised to the peer, MUST include the 3458 ATOMIC_AGGREGATE attribute. 3460 Section 9.1.4 should be updated as follows: 3461 Original text: 3462 If a BGP speaker receives overlapping routes, the Decision 3463 Process 3464 MUST consider both routes based on the configured acceptance 3465 policy. 3466 If both a less and a more specific route are accepted, then the 3467 Decision Process MUST either install both the less and the more 3468 specific routes or it MUST aggregate the two routes and install 3469 the 3470 aggregated route, provided that both routes have the same value 3471 of 3472 the NEXT_HOP attribute. 3474 If a BGP speaker chooses to aggregate, then it MUST add 3475 ATOMIC_AGGREGATE attribute to the route. A route that carries 3476 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3477 NLRI of this route can not be made more specific. Forwarding 3478 along 3479 such a route does not guarantee that IP packets will actually 3480 traverse only ASs listed in the AS_PATH attribute of the route. 3482 Replace with: 3484 It is common practice that more specific routes are often implicitly 3485 aggregated by selecting or advertising only a less-specific route 3486 when overlapping routes are present. As such, all routes SHOULD be 3487 treated as if ATOMIC_AGGREGATE is present and not be made more 3488 specific (de-aggregated). De-aggregation may lead to routing loops. 3490 Section 9.2.2 should remain as it is. 3492 Implications of not making the above updates: 3493 ATOMIC_AGGREGATE is not implemented as documented. Current 3494 operational practices do not seem to often trigger situations that it 3495 was intended to re-mediate. After all, by the way it is currently 3496 documented, many of the routes in the Internet would likely have 3497 ATOMIC_AGGREGATE. 3499 The original motivation for this investigation (aside from a few 3500 years of wondering what this portion of the spec *really* meant) was 3501 making sure the MIB is correctly documented. I can do this now, even 3502 if the spec is not corrected by simply noting that the values: 3503 lessSpecificRouteNotSelected(1), 3504 lessSpecificRouteSelected(2) 3506 mean: 3507 ATOMIC_AGGREGATE not present 3508 ATOMIC_AGGREGATE present 3510 rather than documenting anything about less and more specific routes. 3512 The v2MIB can be fixed to just call it what it is since it hasn't 3513 been RFC'ed yet. 3515 Lastly, the spec would just be incorrect. But all said, nothing bad 3516 would really come of this. 3518 Yakov responded to this, saying that he thought these changes were 3519 reasonable, and unless there were objections, they would be adopted. 3521 Ishi strongly agreed with the changes. 3523 Curtis stated that: 3525 We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated 3526 rather than replaced with an AS_SET. It was always purely 3527 informational since no one intentionally deaggregated and 3528 reannounced. 3530 And suggested that we remove the MUSTs and indicated that this is 3531 only informational. 3533 Jeff replied that: 3535 The point is that by definition of the attribute, anywhere that 3536 policy is used (and some places where it may not be), 3537 ATOMIC_AGGREGATE *should* be there. Since its not, and it would 3538 generally be everywhere, you just shouldn't de-aggregate. 3540 At best, leaving it as a method of informationally signalling 3541 truncation of a AS_PATH is the best we'll get out of it - and it 3542 matches current implementations. 3544 Jonathan agreed with Curtis' idea that we should just move 3545 ATOMIC_AGGREGATE to informational. 3547 Curtis proposed this text: 3549 This existing text is fine: 3551 f) ATOMIC_AGGREGATE (Type Code 6) 3553 ATOMIC_AGGREGATE is a well-known discretionary attribute of 3554 length 0. Usage of this attribute is described in 5.1.6. 3556 This is the existing text that we are considering changing: 3558 5.1.6 ATOMIC_AGGREGATE 3560 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3562 When a router aggregates several routes for the purpose of 3563 advertisement to a particular peer, and the AS_PATH of the aggregated 3564 route excludes at least some of the AS numbers present in the AS_PATH 3565 of the routes that are aggregated, the aggregated route, when 3566 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3568 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3569 attribute MUST NOT remove the attribute from the route when 3570 propagating it to other speakers. 3572 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3573 attribute MUST NOT make any NLRI of that route more specific (as 3574 defined in 9.1.4) when advertising this route to other BGP speakers. 3576 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3577 attribute needs to be cognizant of the fact that the actual path to 3578 destinations, as specified in the NLRI of the route, while having the 3579 loop-free property, may not be the path specified in the AS_PATH 3580 attribute of the route. 3582 Suggested new text: 3584 5.1.6 ATOMIC_AGGREGATE 3586 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3588 When a router aggregates several routes for the purpose of 3589 advertisement to a particular peer, the AS_PATH of the aggregated 3590 route normally includes an AS_SET formed from the set of AS from 3591 which the aggregate was formed. In many cases the network 3592 administrator can determine that the aggregate can safely be 3593 advertised without the AS_SET and not form route loops. 3595 If an aggregate excludes at least some of the AS numbers present in 3596 the AS_PATH of the routes that are aggregated as a result of dropping 3597 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3598 include the ATOMIC_AGGREGATE attribute. 3600 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3601 attribute SHOULD NOT remove the attribute from the route when 3602 propagating it to other speakers. 3604 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3605 attribute MUST NOT make any NLRI of that route more specific (as 3606 defined in 9.1.4) when advertising this route to other BGP speakers. 3608 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3609 attribute needs to be cognizant of the fact that the actual path to 3610 destinations, as specified in the NLRI of the route, while having the 3611 loop-free property, may not be the path specified in the AS_PATH 3612 attribute of the route. 3614 Diffs (for reader convenience): 3616 @@ -4,13 +4,19 @@ ATOMIC_AGGREGATE is a well-known discretionary 3617 attribute. 3619 When a router aggregates several routes for the purpose of 3620 - advertisement to a particular peer, and the AS_PATH of the 3621 - aggregated route excludes at least some of the AS numbers 3622 - present in the AS_PATH of the routes that are aggregated, 3623 - the aggregated route, when advertised to the peer, MUST 3624 - include the ATOMIC_AGGREGATE attribute. 3625 + advertisement to a particular peer, the AS_PATH of the 3626 + aggregated route normally includes an AS_SET formed from the 3627 + set of AS from which the aggregate was formed. In many cases 3628 + the network administrator can determine that the aggregate can 3629 + safely be advertised without the AS_SET and not form route loops. 3630 + 3631 + If an aggregate excludes at least some of the AS numbers present 3632 + in the AS_PATH of the routes that are aggregated as a result of 3633 + dropping the AS_SET, the aggregated route, when advertised to the 3634 + peer, SHOULD include the ATOMIC_AGGREGATE attribute. 3636 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3637 - attribute MUST NOT remove the attribute from the route when 3638 + attribute SHOULD NOT remove the attribute from the route when 3639 + propagating it to other speakers. 3641 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3643 Current text in 9.1.4: 3645 If a BGP speaker chooses to aggregate, then it MUST add 3646 ATOMIC_AGGREGATE attribute to the route. A route that carries 3647 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3648 NLRI of this route can not be made more specific. Forwarding along 3649 such a route does not guarantee that IP packets will actually 3650 traverse only ASs listed in the AS_PATH attribute of the route. 3652 Change to: 3654 If a BGP speaker chooses to aggregate, then it SHOULD either include 3655 all AS used to form the aggregate in an AS_SET or add the 3656 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3657 primarily informational. With the elimination of IP routing 3658 protocols that do not support classless routing and the elimination 3659 of router and host implementations that do not support classless 3660 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3661 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3662 particular MUST NOT be de-aggregated. That is, the NLRI of this route 3663 can not be made more specific. Forwarding along such a route does not 3664 guarantee that IP packets will actually traverse only ASs listed in 3665 the AS_PATH attribute of the route. 3667 This text in 9.2.2.2 need not change. 3669 ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has 3670 ATOMIC_AGGREGATE path attribute, then the aggregated route shall have 3671 this attribute as well. 3673 The appendix need not change: 3675 Appendix 1. Comparison with RFC1771 3677 [...] 3679 Clarifications to the use of the ATOMIC_AGGREGATE attribute. 3681 This might be a bit more wordy that is necessary. It does address 3682 the objections to keeping ATOMIC_AGGREGATE by making the MUST into 3683 SHOULD, and explaining that ATOMIC_AGGREGATE is now primarily 3684 informational. 3686 Yakov was fine with this text. 3688 Yakov posted the text that represents the WG consensus: 3690 Replace: 3692 5.1.6 ATOMIC_AGGREGATE 3694 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3696 When a router aggregates several routes for the purpose of 3697 advertisement to a particular peer, and the AS_PATH of the aggregated 3698 route excludes at least some of the AS numbers present in the AS_PATH 3699 of the routes that are aggregated, the aggregated route, when 3700 advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute. 3702 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3703 attribute MUST NOT remove the attribute from the route when 3704 propagating it to other speakers. 3706 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3707 attribute MUST NOT make any NLRI of that route more specific (as 3708 defined in 9.1.4) when advertising this route to other BGP speakers. 3710 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3711 attribute needs to be cognizant of the fact that the actual path to 3712 destinations, as specified in the NLRI of the route, while having the 3713 loop-free property, may not be the path specified in the AS_PATH 3714 attribute of the route. 3716 with: 3718 5.1.6 ATOMIC_AGGREGATE 3720 ATOMIC_AGGREGATE is a well-known discretionary attribute. 3722 When a router aggregates several routes for the purpose of 3723 advertisement to a particular peer, the AS_PATH of the aggregated 3724 route normally includes an AS_SET formed from the set of AS from 3725 which the aggregate was formed. In many cases the network 3726 administrator can determine that the aggregate can safely be 3727 advertised without the AS_SET and not form route loops. 3729 If an aggregate excludes at least some of the AS numbers present in 3730 the AS_PATH of the routes that are aggregated as a result of dropping 3731 the AS_SET, the aggregated route, when advertised to the peer, SHOULD 3732 include the ATOMIC_AGGREGATE attribute. 3734 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3735 attribute SHOULD NOT remove the attribute from the route when 3736 propagating it to other speakers. 3738 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3739 attribute MUST NOT make any NLRI of that route more specific (as 3740 defined in 9.1.4) when advertising this route to other BGP speakers. 3742 A BGP speaker that receives a route with the ATOMIC_AGGREGATE 3743 attribute needs to be cognizant of the fact that the actual path to 3744 destinations, as specified in the NLRI of the route, while having the 3745 loop-free property, may not be the path specified in the AS_PATH 3746 attribute of the route. 3748 In 9.1.4 replace: 3750 If a BGP speaker chooses to aggregate, then it MUST add 3751 ATOMIC_AGGREGATE attribute to the route. A route that carries 3752 ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the 3753 NLRI of this route can not be made more specific. Forwarding along 3754 such a route does not guarantee that IP packets will actually 3755 traverse only ASs listed in the AS_PATH attribute of the route. 3757 with: 3759 If a BGP speaker chooses to aggregate, then it SHOULD either include 3760 all AS used to form the aggregate in an AS_SET or add the 3761 ATOMIC_AGGREGATE attribute to the route. This attribute is now 3762 primarily informational. With the elimination of IP routing 3763 protocols that do not support classless routing and the elimination 3764 of router and host implementations that do not support classless 3765 routing, there is no longer a need to deaggregate. Routes SHOULD NOT 3766 be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in 3767 particular MUST NOT be de-aggregated. That is, the NLRI of this route 3768 can not be made more specific. Forwarding along such a route does not 3769 guarantee that IP packets will actually traverse only ASs listed in 3770 the AS_PATH attribute of the route. 3772 This met with agreement. This issue is at consensus. 3774 2.59 Section 4.3 - Move text 3776 Status: Consensus 3777 Change: Yes (minimal) 3778 Summary: Update indentation to allow a new "subsection" heading. 3779 Otherwise no change. 3781 Discussion: 3783 This began with this suggestion: 3785 The text about the minimum length, at first look, gives the 3786 impression that it is still part of the NLRI field description and/or 3787 the Path Attributes section. A new "subsection" or heading of some 3788 sort would be helpful in switching context back to the UPDATE message 3789 as a whole and not the path attributes field anymore. 3791 Yakov agreed to update the indentation. 3793 Jonathan agreed, and suggested this text: 3795 " The minimum length of the UPDATE message is 23 octets -- 19 octets 3796 for the fixed header + 2 octets for the Withdrawn Routes Length + 2 3797 octets for the Total Path Attribute Length (the value of Withdrawn 3798 Routes Length is 0 and the value of Total Path Attribute Length is 3799 0)." 3801 Should be moved up to just after 3803 "... the Total Path Attribute Length field and the 3804 Withdrawn Routes Length field." 3806 Yakov responded to this with: 3808 Disagree, as "... the Total Path Attribute Length field and the 3809 Withdrawn Routes Length field." explains how to calculate the length 3810 of NLRI field (and therefore is part of the NLRI field description), 3811 while "The minimum length of the UPDATE message is 23 octets...." 3812 has to do with the length of the UPDATE message. 3814 Jonathan also suggested: 3816 " the value of Withdrawn Routes Length is 0 and the value of Total 3817 Path Attribute Length is 0)." 3819 Should be changed to 3821 " the min. value of Withdrawn Routes Length is 0 and the min. value 3822 of Total Path Attribute Length is 0)." 3824 And Yakov responded with: 3826 Disagree, as the text doesn't talk about what is the minimum value of 3827 the Withdrawn Routes Length and Total Path Attribute Length fields, 3828 but talks about the value of these fields in the case of a min length 3829 UPDATE message. 3831 After Yakov's response and a posting to the list asking that this be 3832 moved to consensus, there were no objections, so this is moved to 3833 consensus. 3835 This is discussed in the "Review: Comments: Section 4.3: UPDATE min 3836 length" thread. 3838 2.60 Section 4.3 - Path Attributes 3840 Status: Consensus 3841 Change: Yes 3842 Summary: Make this change to clarify path attributes in an UPDATE: 3844 To correct the confusion I propose to replace: 3846 A variable length sequence of path attributes is present in every 3847 UPDATE. 3849 with: 3851 A variable length sequence of path attributes is present in every 3852 UPDATE message, except for an UPDATE message that carries only the 3853 withdrawn routes. 3855 Discussion: 3857 This thread began with MikeC pointing out: 3859 The top of page 13 says: 3861 "A variable length sequence of path attributes is present in every 3862 UPDATE." 3864 Is this really true, given that later, in the second to last 3865 paragraph of this section (4.3): 3867 "An UPDATE message might advertise only routes to be withdrawn from 3868 service, in which case it will not include path attributes or Network 3869 Layer Reachability Information." 3871 This could be confusing to a first time reader. 3873 The path attribute length is present in every UPDATE, the path 3874 attribute field itself can be left out, both according to the 3875 description of the minimum length of the UPDATE message and 3876 (implied?) in the picture of the UPDATE message at the beginning of 3877 section 4.3. 3879 This met with one agreement. 3881 Yakov then proposed that: 3883 To correct the confusion I propose to replace: 3885 A variable length sequence of path attributes is present in every 3886 UPDATE. 3888 with: 3890 A variable length sequence of path attributes is present in every 3891 UPDATE message, except for an UPDATE message that carries only the 3892 withdrawn routes. 3894 There was one agreement with this proposal. 3896 This is discussed in the thread: "Review: Section 4.3 - Path 3897 Attributes" 3899 2.61 Next Hop for Redistributed Routes 3901 Status: Consensus 3902 Change: Yes 3903 Summary: More clearly specify the behavior of NEXT_HOP modification, 3904 for the text see the end of the discussion. 3906 Discussion: 3908 Jonathan began this thread with: 3910 I propose adding: 3912 "When announcing a locally originated route to an internal peer, the 3913 BGP speaker should use as the NEXT_HOP the interface address of the 3914 router through which the announced network is reachable for the 3915 speaker; if the route is directly connected to the speaker, or the 3916 interface address of the router through which the announced network 3917 is reachable for the speaker is the internal peer's address, then the 3918 BGP speaker should use for the NEXT_HOP attribute its own IP address 3919 (the address of the interface that is used to reach the peer)." 3921 AFTER 3923 "When sending a message to an internal peer, the BGP speaker should 3924 not modify the NEXT_HOP attribute, unless it has been explicitly 3925 configured to announce its own IP address as the NEXT_HOP." 3927 There has been no discussion on this. 3929 This is discussed in the "Next hop for redistributed routes" thread. 3931 Issue 14 closed in favor of this issue. 3933 In response to Yakov's call for input, Michael responded that: 3935 Section 5.1.3 explicitly states what to do when originating to an 3936 external peer. #2 covers one hop away, #3 covers more than on hop 3937 away. #1 talks about sending to an iBGP peer, but only when 3938 propagating a route received from an eBGP peer. 3940 1) When sending a message to an internal peer, the BGP speaker should 3941 not modify the NEXT_HOP attribute, unless it has been explicitly 3942 configured to announce its own IP address as the NEXT_HOP. 3944 Text similar to #2 should be added, in their own bullet items to #1 3945 such as what was suggested by Jonathan Natale (text is above.) 3947 Yakov replied with this: 3949 Replace: 3951 1) When sending a message to an internal peer, the BGP speaker should 3952 not modify the NEXT_HOP attribute, unless it has been explicitly 3953 configured to announce its own IP address as the NEXT_HOP. 3955 with: 3957 1) When sending a message to an internal peer, if the route is not 3958 locally originated the BGP speaker should not modify the NEXT_HOP 3959 attribute, unless it has been explicitly configured to announce its 3960 own IP address as the NEXT_HOP. When announcing a locally originated 3961 route to an internal peer, the BGP speaker should use as the NEXT_HOP 3962 the interface address of the router through which the announced 3963 network is reachable for the speaker; if the route is directly 3964 connected to the speaker, or the interface address of the router 3965 through which the announced network is reachable for the speaker is 3966 the internal peer's address, then the BGP speaker should use for the 3967 NEXT_HOP attribute its own IP address (the address of the interface 3968 that is used to reach the peer). 3970 And stated the change would be made if there were no objections. 3971 There have been no objections, so this is at consensus. 3973 2.62 Deprecate BGP Authentication Optional Parameter from RFC1771 3975 Status: Consensus 3976 Change: Yes 3977 Summary: We are at consensus, in that we agree that we should 3978 deprecate the BGP Authentication Optional Parameter as described in 3979 RFC1771 in favor of the mechanism described in RFC2385. The textual 3980 changes are listed at the end of the discussion section of this 3981 issue. 3983 Discussion: 3985 This discussion started in issue 21: Authentication Text Update. 3987 This topic has come up before (July time frame), but was recently 3988 refreshed in the context of issue 21. It began with some questions 3989 to the list as to who used what sort of authentication mechanisms. 3990 From the responses it was clear that MD5 (RFC2385) was the preferred 3991 method. 3993 Eric Gray's message helps to flesh this out: 3995 The question is not whether MD5 authentication is used, it is how is 3996 it implemented in real BGP implementations or - more importantly - 3997 where is the authentication information located in the packets sent 3998 between two BGP peers? This is not strictly an implementation issue 3999 because authentication information is located in different places 4000 depending on which version of MD5 authentication is in use. 4002 As is generally known, options are not necessarily good. Currently, 4003 between RFC 1771 and RFC 2385, there are two very distinct ways to 4004 accomplish a semantically identical function. If the mechanism 4005 defined in RFC 1771 is not supported by a number of interoperable 4006 implementations, it must be deprecated per RFC 2026 prior to 4007 advancing the specification to Draft Standard. If it is not 4008 implemented and actually in use, it should be deprecated if for no 4009 other reason than to make the 4011 To this Yakov responded: 4013 To be more precise, 4015 In cases in which one or more options or features have not been 4016 demonstrated in at least two interoperable implementations, the 4017 specification may advance to the Draft Standard level only if those 4018 options or features are removed. 4020 So, the relevant question is whether we have at least two 4021 implementations that support authentication as described in rfc1771. 4023 Folks who implemented authentication, as described in rfc1771, please 4024 speak up. 4026 There have been no responses to Yakov's question. 4028 There seems to be a consensus that, since it is little used, and 4029 since there are better mechanisms, namely MD5 authentication, we 4030 should deprecate the BGP Authentication Optional Parameter from 4031 RFC1771. 4033 Ok, after some discussion, this is a list of the text that we are 4034 adding, changing or removing: 4036 1) Remove the reference to the authentication optional parameter: 4038 I would suggest to remove the following text from the draft: 4040 This document defines the following Optional Parameters: 4042 a) Authentication Information (Parameter Type 1): 4044 This optional parameter may be used to authenticate a BGP 4045 peer. The Parameter Value field contains a 1-octet 4046 Authentication Code followed by a variable length 4047 Authentication Data. 4049 0 1 2 3 4 5 6 7 8 4050 +-+-+-+-+-+-+-+-+ 4051 | Auth. Code | 4052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4053 | | 4054 | Authentication Data | 4055 | | 4056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4058 Authentication Code: 4060 This 1-octet unsigned integer indicates the 4061 authentication mechanism being used. Whenever an 4062 authentication mechanism is specified for use within 4063 BGP, three things must be included in the 4064 specification: 4066 - the value of the Authentication Code which indicates 4067 use of the mechanism, 4068 - the form and meaning of the Authentication Data, and 4069 - the algorithm for computing values of Marker fields. 4071 Note that a separate authentication mechanism may be 4072 used in establishing the transport level connection. 4074 Authentication Data: 4076 Authentication Data is a variable length field that is 4077 interpreted according to the value of the 4078 Authentication Code field. 4080 2) Update the introduction: 4082 In section 2 (Introduction), sixth paragraph 4084 From: 4086 BGP runs over a reliable transport protocol. This eliminates the need 4087 to implement explicit update fragmentation, retransmission, 4088 acknowledgment, and sequencing. Any authentication scheme used by the 4089 transport protocol (e.g., RFC2385 [10]) may be used in addition to 4090 BGP's own authentication mechanisms. The error notification mechanism 4091 used in BGP assumes that the transport protocol supports a "graceful" 4092 close, i.e., that all outstanding data will be delivered before the 4093 connection is closed. 4095 To: 4097 BGP uses TCP [RFC793] as its transport protocol. This eliminates the 4098 need to implement explicit update fragmentation, retransmission, 4099 acknowledgment, and sequencing. BGP listens on TCP port 179. Any 4100 authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be 4101 used. The error notification mechanism used in BGP assumes that TCP 4102 supports a "graceful" close, i.e., that all outstanding data will be 4103 delivered before the connection is closed. 4105 3) Update the message header format section: 4107 From: 4109 Marker: 4111 This 16-octet field contains a value that the receiver of the 4112 message can predict. If the Type of the message is OPEN, or if 4113 the OPEN message carries no Authentication Information (as an 4114 Optional Parameter), then the Marker must be all ones. 4115 Otherwise, the value of the marker can be predicted by some a 4116 computation specified as part of the authentication mechanism 4117 (which is specified as part of the Authentication Information) 4118 used. The Marker can be used to detect loss of synchronization 4119 between a pair of BGP peers, and to authenticate incoming BGP 4120 messages. 4122 To: 4124 Marker: 4126 This 16-octet field is included for compatibility; it must be 4127 set to all ones. 4129 4) Update the Message Header error handling section: 4131 In section 6.1 (Message Header error handling), second paragraph 4133 From: 4135 The expected value of the Marker field of the message header is all 4136 ones if the message type is OPEN. The expected value of the Marker 4137 field for all other types of BGP messages determined based on the 4138 presence of the Authentication Information Optional Parameter in the 4139 BGP OPEN message and the actual authentication mechanism (if the 4140 Authentication Information in the BGP OPEN message is present). If 4141 the Marker field of the message header is not the expected one, then 4142 a synchronization error has occurred and the Error Subcode is set to 4143 Connection Not Synchronized. 4145 To: 4147 The expected value of the Marker field of the message header is all 4148 ones. If the Marker field of the message header is not as expected, 4149 then a synchronization error has occurred and the Error Subcode is 4150 set to Connection Not Synchronized. 4152 5) Remove a paragraph from the OPEN message error handling section 4153 (section 6.2): 4155 If the OPEN message carries Authentication Information (as an 4156 Optional Parameter), then the corresponding authentication procedure 4157 is invoked. If the authentication procedure (based on Authentication 4158 Code and Authentication Data) fails, then the Error Subcode is set to 4159 Authentication Failure. 4161 6) Update the "Differences from RFC1771 Appendix" 4163 Text not listed here 4165 7) Fix the hole in the numbering by updating: 4167 From: 4169 This document defines the following Optional Parameters: 4171 a) Authentication Information (Parameter Type 1): 4173 To: 4175 This document defines the following Optional Parameters: 4177 a) Optional parameter type 1, Authentication Information, has been 4178 deprecated. 4180 We are at consensus with these changes. 4182 2.63 Clarify MED Removal Text 4184 Status: Consensus 4185 Change: Yes 4186 Summary: Modify text to clear up MED removal behavior. Text is at 4187 the end of the discussion. 4189 Discussion: 4191 This discussion began when Jonathan posted a question to the list: 4193 In reference to: 4195 "A BGP speaker MUST IMPLEMENT a mechanism based on local 4196 configuration which allows the MULTI_EXIT_DISC attribute to be 4197 removed from a route" 4199 Does anybody know how this can be done in IOS??? Looks like it 4200 cannot. 4202 Juniper??? 4204 Other code??? 4206 Change to "SHOULD"??? 4208 Enke responded that: 4210 As the MED value is treated as zero when the MED attribute is 4211 missing, removing the MED attribute is really equivalent to setting 4212 the value to zero. Based on this logic, one can argue that "MED 4213 removal" is supported by multiple vendors. 4215 However, I do see that the current text can be consolidated and 4216 cleaned up: 4218 ------------------------ 4219 5.1.4 MULTI_EXIT_DISC 4221 ... 4223 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4224 which allows the MULTI_EXIT_DISC attribute to be removed from a 4225 route. This MAY be done prior to determining the degree of preference 4226 of the route and performing route selection (decision process phases 4227 1 and 2). 4229 An implementation MAY also (based on local configuration) alter the 4230 value of the MULTI_EXIT_DISC attribute received over an external 4231 link. If it does so, it shall do so prior to determining the degree 4232 of preference of the route and performing route selection (decision 4233 process phases 1 and 2). 4235 ------------------------- 4237 How about this: 4239 A BGP speaker MUST implement a mechanism based on local configuration 4240 which allows the value of MULTI_EXIT_DISC attribute of a received 4241 route to be altered. This shall be done prior to determining the 4242 degree of preference of the route and performing route selection 4243 (decision process phases 1 and 2). 4245 -------------------------- 4247 In responding to a question, Enke also added: 4249 > Humm. I thought with a missing MED it was preferable to be treated 4250 > as worst not as 0. 4252 It was changed a long time ago. Please see the following text in 4253 Sect. 9.1.2.2 of the draft: 4255 In the pseudo-code above, MED(n) is a function which returns the 4256 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4257 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4258 MULTI_EXIT_DISC value, i.e. 0. 4260 Curtis replied to Enke: 4262 If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a 4263 knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should 4264 change the spec to say that MED(n) returns the largest value possible 4265 is MULTI_EXIT_DISC is missing since this has better loop suppression 4266 behavior if the placement of MULTI_EXIT_DISC removal is moved in its 4267 position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out. In 4268 other words, no matter where the removal takes place, we are loop 4269 free without special rules about comparing EBGP before MED removal 4270 and then IBGP after MED removal. The only argument for MED(n) going 4271 to zero for missing MULTI_EXIT_DISC was that Cisco routers did that 4272 (and change would pose an operational issue if there wasn't a knob to 4273 facilitate the change). 4275 Note that when explicitly jamming a MULTI_EXIT_DISC value, such as 4276 zero, the issue of where in the decision process the MULTI_EXIT_DISC 4277 learned from the EBGP peers could still be used becomes a concern 4278 again. Unfortunately these implementation hints are necessary to 4279 remain loop free and so its hard to declare them out of scope, unless 4280 we forbid changing MULTI_EXIT_DISC and just allow it to be removed 4281 (which does not reflect current practice). 4283 Curtis also added: 4285 The other issue was MED handling. In "5.1.4 MULTI_EXIT_DISC": 4287 A BGP speaker MUST IMPLEMENT a mechanism based on local configuration 4288 which allows the MULTI_EXIT_DISC attribute to be removed from a 4289 route. This MAY be done prior to determining the degree of preference 4290 of the route and performing route selection (decision process phases 4291 1 and 2). 4293 An implementation MAY also (based on local configuration) alter the 4294 value of the MULTI_EXIT_DISC attribute received over an external 4295 link. If it does so, it shall do so prior to determining the degree 4296 of preference of the route and performing route selection (decision 4297 process phases 1 and 2). 4299 This doesn't sufficiently address the issue. 4301 The MED step in the decision process is (in 9.1.2.2): 4303 c) Remove from consideration routes with less-preferred 4304 MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable 4305 between routes learned from the same neighboring AS. Routes which do 4306 not have the MULTI_EXIT_DISC attribute are considered to have the 4307 lowest possible MULTI_EXIT_DISC value. 4309 This is also described in the following procedure: 4311 for m = all routes still under consideration 4312 for n = all routes still under consideration 4313 if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) 4314 remove route m from consideration 4316 In the pseudo-code above, MED(n) is a function which returns the 4317 value of route n's MULTI_EXIT_DISC attribute. If route n has no 4318 MULTI_EXIT_DISC attribute, the function returns the lowest possible 4319 MULTI_EXIT_DISC value, i.e. 0. 4321 Similarly, neighborAS(n) is a function which returns the neighbor AS 4322 from which the route was received. 4324 The problem is that a route loop can be formed. 4326 To avoid the route loop, two suggestions were made (2-3 years ago and 4327 nothing was done). One was to make MED(n) return infinity if there 4328 was no MULTI_EXIT_DISC. The other was to consider MULTI_EXIT_DISC in 4329 the decision process only for the purpose of selecting among the EBGP 4330 peers, then remove MULTI_EXIT_DISC, then use that best route in 4331 comparisons to IBGP learned routes. 4333 The statement in 5.1.4 "This MAY be done prior to determining the 4334 degree of preference of the route and performing route selection 4335 (decision process phases 1 and 2)" does not sufficiently address 4336 this. This implies that you MAY also remove after route selection, 4337 in which case field experience indicates you WILL get burned (unless 4338 you know about the caveat above). Initially this came up as an 4339 interoperability issue but later it was proven (in the field) that a 4340 Cisco and another Cisco could form a route loop until Cisco made this 4341 change. 4343 Additional wording is needed either in 5.1.4 or in 9.1.2.2. I 4344 suggest we put a forward reference in 5.1.4: 4346 [...]. This MAY be done prior to determining the degree of preference 4347 of the route and performing route selection (decision process phases 4348 1 and 2). See section 9.1.2.2 for necessary restricts on this. 4350 Then in 9.1.2.2 add a clarification to the neighborAS(n) function and 4351 add to the existing text. 4353 Similarly, neighborAS(n) is a function which returns the neighbor AS 4354 from which the route was received. If the route is learned via IBGP, 4355 it is the neighbor AS from which the other IBGP speaker learned the 4356 route, not the internal AS. 4358 If a MULTI_EXIT_DISC attribute is removed before redistributing a 4359 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4360 in the comparison of EBGP learned routes, them removed, then the 4361 remaining EBGP learned route may be compared to the remaining IBGP 4362 learned routes, without considering the MULTI_EXIT_DISC attribute for 4363 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4364 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4365 learned route in the comparison with an IBGP learned route, then 4366 dropping the MULTI_EXIT_DISC and advertising the route has been 4367 proven to cause route loops. 4369 The loop is the classic I prefer your and you prefer mine problem. 4370 It occurs when the router is configured to remove MULTI_EXIT_DISC and 4371 advertise out a route so other routers can use IGP cost to select the 4372 best route. If two routers do this, as soon as they hear the route 4373 with no MULTI_EXIT_DISC from the other peer they start forwarding 4374 toward that peer but they continue to advertise to it since others 4375 IBGP peers are expected to select among the MULTI_EXIT_DISC free IBGP 4376 learned routes using the next step in the decision process, IGP cost. 4378 In this case, what you want is each router to prefer its own EBGP 4379 route, even though it has a MULTI_EXIT_DISC and the IBGP learned 4380 route from the same neighbor AS has had its MULTI_EXIT_DISC stripped 4381 off (or didn't have one, you can't tell which it is). You then want 4382 all of the IBGP peers with a MULTI_EXIT_DISC free route from that AS, 4383 or that have stripped the MULTI_EXIT_DISC to form one, to advertise 4384 them. Others in the AS will then use IGP cost to further resolve 4385 which exit point to use. It make a difference when the route is the 4386 aggregate route of another major provider. IGP cost yields what ISPs 4387 call "hot potatoe routing" and MED selects among multiple heavily 4388 loaded provider interconnects. 4390 [Aside: Having a missing MULTI_EXIT_DISC default to infinity would do 4391 exactly what the ISPs want it to do in the first place and be a lot 4392 easier to explain but we didn't fix that 2-3 years ago when the issue 4393 came up even though we had WG consensus that it was the right thing 4394 to do. The authors didn't act on it at the time (because Cisco 4395 didn't do it that way and the authors preferred to sit on the draft). 4396 At this point we might as well adequately document what we ended up 4397 with.... End of soap box. I don't take myself all that seriously so 4398 others shouldn't either. :-)] 4400 After some more discussion on this, we have this text: 4402 In 5.1.4 replace: 4404 An implementation MAY also (based on local configuration) alter the 4405 value of the MULTI_EXIT_DISC attribute received over EBGP. If it 4406 does so, it shall do so prior to determining the degree of preference 4407 of the route and performing route selection (decision process phases 4408 1 and 2). 4410 with: 4412 An implementation MAY also (based on local configuration) alter the 4413 value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY 4414 be done prior to determining the degree of preference of the route 4415 and performing route selection (decision process phases 1 and 2). See 4416 section 9.1.2.2 for necessary restricts on this. 4418 In 9.1.2.2 replace: 4420 Similarly, neighborAS(n) is a function which returns the neighbor AS 4421 from which the route was received. 4423 with: 4425 Similarly, neighborAS(n) is a function which returns the neighbor AS 4426 from which the route was received. If the route is learned via IBGP, 4427 and the other IBGP speaker didn't originate the route, it is the 4428 neighbor AS from which the other IBGP speaker learned the route. If 4429 the route is learned via IBGP, and the other IBGP speaker originated 4430 the route, it is the local AS. 4432 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 4433 route into IBGP, the MULTI_EXIT_DISC attribute may only be considered 4434 in the comparison of EBGP learned routes, then removed, then the 4435 remaining EBGP learned route may be compared to the remaining IBGP 4436 learned routes, without considering the MULTI_EXIT_DISC attribute for 4437 those EBGP learned routes whose MULTI_EXIT_DISC will be dropped 4438 before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP 4439 learned route in the comparison with an IBGP learned route, then 4440 dropping the MULTI_EXIT_DISC and advertising the route has been 4441 proven to cause route loops. 4443 There have been no objections to this, so we are at consensus. 4445 2.64 MED for Originated Routes 4447 Status: Consensus 4448 Change: No 4449 Summary: The consensus is that there is not need to specify default 4450 values for MED in the base draft. 4452 Discussion: 4454 This issue began when it was pointed out that we do not specify the 4455 default values for MED in the base draft. 4457 There were a variety of responses, but the consensus is that since 4458 this is not relevant for interoperability, this does not need to be 4459 in the base spec. 4461 2.65 Rules for Aggregating with MED and NEXT_HOP 4463 Status: Consensus 4464 Change: Yes 4465 Summary: Clear up the text on aggregating with a MED. See the 4466 discussion for the text. 4468 Discussion: 4470 There is a proposal to relax this statement: 4472 "Routes that have the following attributes shall not be aggregated 4473 unless the corresponding attributes of each route are identical: 4474 MULTI_EXIT_DISC, NEXT_HOP." 4476 In his reply to the original mail, Curtis asserted that we should 4477 leave the MED rules alone, but perhaps we could relax the NEXT_HOP 4478 statement. 4480 This was revisited in the "aggregating with MED and NEXT_HOP" thread. 4482 Yakov suggested we replace: 4484 Routes that have the following attributes shall not be aggregated 4485 unless the corresponding attributes of each route are identical: 4486 MULTI_EXIT_DISC, NEXT_HOP. 4488 If the aggregation occurs as part of the update process, routes with 4489 different NEXT_HOP values can be aggregated when announced through an 4490 external BGP session. 4492 Path attributes that have different type codes can not be aggregated 4493 together. Path attributes of the same type code may be aggregated, 4494 according to the following rules: 4496 with: 4498 Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be 4499 aggregated. 4501 Path attributes that have different type codes can not be aggregated 4502 together. Path attributes of the same type code may be aggregated, 4503 according to the following rules: 4505 NEXT_HOP: When aggregating routes that have different NEXT_HOP 4506 attribute, the NEXT_HOP attribute of the aggregated route SHALL 4507 identify an interface on the router that performs the aggregation. 4509 This met with agreement. 4511 Dimitry asked if the "Routes that have different MULTI_EXIT_DESC 4512 attribute SHALL NOT be aggregated." sentence was unnecessary since it 4513 should be a matter of local policy. Jeff replied that it has been 4514 mentioned that removing this stipulation can cause routing loops. 4516 We are at consensus with this issue. 4518 2.66 Complex AS Path Aggregating 4520 Status: Consensus 4521 Change: No 4522 Summary: Since we have two implementations of this method, section 4523 6.8 stays in the specification. 4525 Discussion: 4527 Jonathan opened this discussion with: 4529 The part in the draft about complex AS path aggregation could/should 4530 be deleted. The current draft implies that when aggregating, for 4531 example (1st): 4533 1 2 4 3 4535 w/ 4537 3 4 6 5 4539 and 4541 5 6 7 8 4543 then 4545 1 2 {3 4 5 6} 7 8 4547 ...would be OK 4549 AFAIK, all implementations aggregate by either: (2nd)putting ONLY the 4550 local AS in the path (and setting the atomic) OR (3rd)by creating 1 4551 giant set and adding the local AS as a seq. 4553 So he proposed we remove this to reflect current code. 4555 Jeff replied that there is absolutely nothing wrong with doing 4556 complex aggregation, and there is no reason to remove this from the 4557 specification. 4559 Yakov responded that: 4561 Jonathan is certainly correct that the spec has to reflect current 4562 code. Therefore, unless there are at least two (interoperable) 4563 implementations that implement the algorithm described in "6.8 4564 Complex AS_PATH aggregation", this section has to be removed (this is 4565 irrespective of whether there is something wrong, or nothing wrong 4566 with complex aggregation). With this in mind, if you implement this 4567 algorithm please speak up within a week. If within a week we 4568 wouldn't know that there are at least two implementations the section 4569 will be removed. And likewise, if we hear that there are at least two 4570 implementations, the section will stay. 4572 Jeff replied: 4574 I am also fine with removing it. I just don't think its necessary, 4575 especially if One Of These Days someone decides that running policy 4576 based on as-adjacencies would be a Nice Thing and fixes their 4577 implementation to support "complex" aggregation of paths. 4579 That said, I am aware of no one who implements this. 4581 As an aside, in the thread "last thought on complex aggregation" Jeff 4582 supplied: 4584 I finally remembered what was bothering me about removing complex 4585 aggregation from the spec. 4587 If it is removed, people who do conformance tests and some 4588 implementations may take this to mean "it shall be illegal to have an 4589 AS_PATH that contains a SEQUENCE of a particular type after a SET". 4591 This would make a perfectly ok AS_PATH into one that isn't legal, 4592 even if no implementation currently generates it. 4594 Jonathan replied that he thought the issue was moot since no one has 4595 implemented this. 4597 John replied that, although he is a bit uncomfortable in removing 4598 this from the spec, he doesn't see any harm in doing so. 4600 With this in mind, Yakov suggested we consider the issue closed. 4602 So we will wait a week from 10/17 to see if anyone chimes in. 4604 Siva responded that they have implemented this functionality. So we 4605 need one more...Ben responded that they support this at Marconi as 4606 well. 4608 So we have two implementations, the section stays in the spec. We 4609 are at consensus with this issue. 4611 2.67 Counting AS_SET/AS_CONFED_* 4613 Status: Consensus 4614 Change: Yes 4615 Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to 4616 the BGP Confederations document. Update the base draft to reflect 4617 this by changing section 9.1.2.2. Specific text is at the end of the 4618 discussion. 4620 Discussion: 4622 Jonathan brought up some questions on how current implementations 4623 count AS_SET and AS_CONFED_* 4625 There were a variety of responses to this, answering his questions. 4626 Curtis pointed out that this behavior is covered in: 4628 That's in 9.1.2.2: 4630 a) Remove from consideration all routes which are not tied for having 4631 the smallest number of AS numbers present in their AS_PATH 4632 attributes. Note, that when counting this number, an AS_SET counts as 4633 1, no matter how many ASs are in the set, and that, if the 4634 implementation supports [13], then AS numbers present in segments of 4635 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4636 count of AS numbers present in the AS_PATH. 4638 Jonathan replied that this might be at odds with what Juniper does, 4639 although he was unsure, and asked for clarification. 4641 This was discussed in the "New Issue AS path" thread. 4643 Yakov proposed that: 4645 The issue of route selection in the present of confederations belongs 4646 *not* to the base spec, but to the spec that describes BGP Confeds. 4647 With this in mind I would suggest to change in 9.1.2.2 from 4649 a) Remove from consideration all routes which are not tied for having 4650 the smallest number of AS numbers present in their AS_PATH 4651 attributes. Note, that when counting this number, an AS_SET counts as 4652 1, no matter how many ASs are in the set, and that, if the 4653 implementation supports [13], then AS numbers present in segments of 4654 type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the 4655 count of AS numbers present in the AS_PATH. 4657 to 4659 a) Remove from consideration all routes which are not tied for having 4660 the smallest number of AS numbers present in their AS_PATH 4661 attributes. Note, that when counting this number, an AS_SET counts as 4662 1, no matter how many ASs are in the set. 4664 and ask the authors of BGP Confeds to update their document to cover 4665 how the presence of confeds impact route selection. 4667 This met with agreement, this issue is at consensus. 4669 2.68 Outbound Loop Detection 4671 Status: Consensus 4672 Change: No 4673 Summary: The consensus is, that while this may be a useful technique, 4674 it would break existing methods, and is otherwise out-of-scope for 4675 the base draft. It was suggested that this could be addressed in the 4676 update to RFC1772. 4678 Discussion: 4680 Jonathan brought up that: 4682 This paper (thanks Jeff) 4683 http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR- 4684 TR-2000-08 indicates that it is better to do the loop detection 4685 outbound as well inbound. The current draft indicates that it only 4686 needs to be done inbound. IOS does it inbound as well as outbound. 4687 GateD/Juniper does it (did it ???) only inbound. 4689 So I propose we add: "An implementation MAY choose to not advertise 4690 routes to EBGP peers if these routes contain the AS of that peer in 4691 the AS path." after: "If the autonomous system number appears in the 4692 AS path the route may be stored in the Adj-RIB In, but unless the 4693 router is configured to accept routes with its own AS in the AS path, 4694 the route shall not be passed to the BGP Decision Process." 4696 *If there is at least one other implementation that does outbound 4697 pruning/loop-detection.* 4699 Yakov pointed out that this is ONLY applicable to the base draft if 4700 there are multiple implementations doing this. This issue will only 4701 be considered if these implementors come forward by 10/25/02. 4702 Otherwise the issue will be considered closed. 4704 Jeff replied that there was more at stake with this than if people 4705 had implemented it: 4707 My suggestion is that this can stay out of the base draft. While it 4708 is true that this speeds up convergence (per the paper), it doesn't 4709 affect interoperability. 4711 Also, adding this specifically removes the ability from several 4712 implementations to be able to bridge a partitioned AS by permitting 4713 loops. (I'm not going to argue whether this is a Good way to do 4714 this, just that its done.) 4716 Its also worth noting that one could produce the same resultant 4717 speed-up by detecting the loop on an outbound basis and *not* 4718 applying the min*timers to the UPDATE. Thus, this would be a case 4719 of an advertisement of NLRI being treated the same, timer-wise, as 4720 the advertisement of WD_NLRI. 4722 I would suggest moving this suggestion for outbound loop detection 4723 in one form or another to the 1772 replacement. 4725 Yakov agreed with this. 4727 2.69 Appendix A - Other Documents 4729 Over the course of this discussion, a number of issues have been 4730 raised that the group though would be better dealt with in other 4731 documents. These additional documents, and their concomitant issues 4732 will be more fully addressed when the WG turns its focus to them. 4733 These projects are: 4735 1) Update RFC 1772: Application of the Border Gateway Protocol in the 4736 Internet. This will probably entail a complete rewrite. 2) Update 4737 Route Reflector (2796) and Confederation (3065) RFC's regarding their 4738 impact on route selection. 3) Write a new document covering BGP 4739 Multipath. 4740 2. The Issues from -18 to -19. 4742 This section lists the issues discussed on the list from November 4743 2002 to late February 2003. 4745 3.1 Reference to RFC 1772 4747 Status: Consensus 4748 Change: No 4749 Summary: Proposed changing RFC 1772 reference, since that document 4750 should be updated. 4752 Discussion: 4754 Jeff proposed that we reconsider referencing RFC 1772, since that 4755 document should be updated. 4757 Yakov pointed out that this is a non-normative reference and can just 4758 be left as is. 4760 Jeff agreed that this wasn't a big deal. We are at consensus to 4761 leave things as they are. 4763 This was discussed in the "-18 last call comments" thread. 4765 3.2 MUST/SHOULD Capitalization 4767 Status: Consensus 4768 Change: Yes 4769 Summary: Capitalize MUST/SHOULD where appropriate. 4771 Discussion: 4773 Jeff brought this up, and Yakov responded asking that he point out 4774 specific instances where this is needed. Jeff said he would do so, 4775 given some time. 4777 Yakov later replied that this would be fixed in the -19 version. 4779 Jeff replied with a master diff showing the MUST/SHOULDs, for the 4780 entire document please see the beginning of the thread entitled: 4781 "Issues list, #2: MUST/SHOULD Capitalization" 4783 This was discussed in the "18 last call comments" thread. This was 4784 also brought up in the "proxy: comments on draft -18" thread. 4786 3.3 Fix Update Error Subcode 7 -- accidently removed. 4788 Status: Consensus 4789 Change: Yes 4790 Summary: Add error subcode 7 back in, it looks like it was 4791 inadvertently removed. Add deprecation text to Open Message Error 4792 subcode 5. 4794 Discussion: 4796 Jeff supplied: 4798 Update message error subcode 7 is removed. Especially in -18, 4799 it looks like an editing mistake based on where it would fall 4800 in the editing.. 4802 Yakov mentioned that this is addressed in Appendix A. 4804 Jeff replied: 4806 What I would like to see is something like this: 4808 6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 - 4809 Invalid NEXT_HOP Attribute 4811 As it stands, 7 lies on a page boundary and looks like it got 4812 clipped by the roff. 4814 Yakov agreed, and also said he would add similar text for Open 4815 Message Error subcode 5. 4817 This was discussed in the "18 last call comments" thread. 4819 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 4853 Status: Consensus 4854 Change: Yes 4855 Summary: Update the text to reflect the AS Loop detection should be 4856 done in the BGP decision process. 4858 Discussion: 4860 John brought this up, and suggested: 4862 I have one further comment just in case it's not perfectly obvious 4863 to everyone, which is that "ignore the UPDATE" is not strictly the 4864 action you take when receiving a looped update. Rather, you treat 4865 it as an implicit withdraw, i.e. you process it as any other update 4866 but treat the contained NLRI as unfeasible. 4868 I was going to write that this is sufficiently clear from the spec, 4869 but I regret to say that it isn't. Here is the fourth paragraph of 4870 section 9: 4872 The information carried by the AS_PATH attribute is checked for 4873 AS loops. AS loop detection is done by scanning the full AS path 4874 (as specified in the AS_PATH attribute), and checking that the 4875 autonomous system number of the local system does not appear in 4876 the AS path. If the autonomous system number appears in the AS 4877 path the route may be stored in the Adj-RIB-In, but unless the 4878 router is configured to accept routes with its own autonomous 4879 system in the AS path, the route shall not be passed to the BGP 4880 Decision Process. Operations of a router that is configured to 4881 accept routes with its own autonomous system number in the AS 4882 path are outside the scope of this document. 4884 I don't think this is quite right -- the decision process needs to 4885 be run if the looped routes had previously been advertised feasibly 4886 on the same session. This could be fixed by hacking the quoted 4887 paragraph, but it seems more straightforward to do it by removing 4888 the quoted paragraph and making the fix in 9.1.2 Phase 2 instead. 4889 This could be done by inserting the following between the third and 4890 fourth paragraphs of 9.1.2 Phase 2: 4892 If the AS_PATH attribute of a BGP route contains an AS loop, the 4893 BGP route should be excluded from the Phase 2 decision function. 4894 AS loop detection is done by scanning the full AS path (as 4895 specified in the AS_PATH attribute), and checking that the 4896 autonomous system number of the local system does not appear in 4897 the AS path. Operations of a router that is configured to 4898 accept routes with its own autonomous system number in the AS 4899 path are outside the scope of this document. 4901 Section 9.3, first bullet, also addresses this topic, but I don't 4902 think it's sufficient. 4904 Yakov agreed that this was a change for the better and will include 4905 this in the next revision. 4907 We are at consensus on this issue. 4909 This is discussed in the "-18 last call comments" thread. 4911 3.7 Standardize FSM Timer Descriptions 4913 Status: Consensus 4914 Change: Yes 4915 Summary: Standardize the state descriptions on those listed in the 4916 discussion section of this issue. 4918 Discussion: 4920 Tom proposed: 4922 I think a standard description would serve us better instead of 4923 using the following different ways (which I take all to refer to 4924 the same entity): 4926 delayBGP open timer 4927 BGP delay open timer 4928 BGP open delay timer 4929 delay open timer 4930 BGP delay timer 4932 I suggest Open Delay timer (with those capitals) 4934 I believe that the corresponding flag is consistently referred to 4935 (apart from the capitalization) as Delay Open flag 4937 Yakov agreed with this suggestion, no one else disagreed, we are at 4938 consensus. 4940 This was discussed in the "BGP18-FSM-terminology" thread. 4942 3.8 FSM MIB enumerations 4944 Status: Consensus 4945 Change: Yes 4946 Summary: Move MIB references from the base spec into the MIB 4947 document. 4949 Discussion: 4951 Tom pointed out that: 4953 The FSM makes several references to putting values into MIB objects 4954 and while some of the values are defined, eg FSM error or Hold Timer 4955 expired, I can find no definition of the following in any of the BGP 4956 documents, MIB or otherwise. 4958 connect retry expired 4959 TCP disconnect 4960 administrative down 4961 collision detect closure 4962 Call Collision cease 4963 collision detected and dump connection 4964 Administrative stop 4966 I believe an implementation needs to be told these values somewhere 4967 and that there should be a reference to that place in bgp18. 4969 Jeff replied that to make things easier, the MIB references will be 4970 removed from the base spec, and into the MIB document. 4972 This was discussed in the "WG Last Call FSM MIB enumeration" thread, 4973 and the "bgp18 WG Last Call fsm MIB objects" thread. 4975 3.9 Make "delete routes" language consistent 4977 Status: Consensus 4978 Change: Yes 4979 Summary: Replace a variety of wording with "deletes all routes 4980 associated with this connection,". 4982 Discussion: 4984 Tom pointed out that we use a variety of language to say how we are 4985 going to delete routes in the FSM. He proposed that we instead use: 4987 - deletes all routes associated with this connection, 4989 This met with agreement, and will be reflected in the next version. 4991 This was discussed in the "bgp18 WG Last Call fsm delete action" 4992 thread. 4994 3.10 Correct OpenSent and OpenConfirm delete wording 4996 Status: Consensus 4997 Change: Yes 4998 Summary: Remove delete wording from OpenSent and OpenConfirm states. 5000 Discussion: 5002 Venu asked why there was delete wording in the OpenSent and 5003 OpenConfirm states when a BGP speaker cannot receive routes in these 5004 states. 5006 Jeff acknowledged that this was an error. Yakov agreed to fix the 5007 next version. 5009 This was discussed in the "bgp18 WG Last Call fsm delete action" 5010 thread. 5012 3.11 Incorrect next state when the delay open timer expires. 5014 Status: Consensus 5015 Change: Yes 5016 Summary: Fix the next state. 5018 Discussion: 5020 Tom pointed out that: 5022 I believe that there is an incorrect next state when the delay open 5023 timer expires [event 12] in the Active state. The next state should 5024 be OpenSent and not OpenConfirm. 5026 OpenConfirm is for KeepAlive processing when Open messages have been 5027 sent and received. 5029 OpenSent is for Open sent and not yet received. 5031 The corresponding section in Connect state I believe is correct. 5033 Yakov agreed, and will fix this in the next revision. 5035 This was discussed in the "bgp18 WG Last Call fsm incorrect next 5036 state" 5038 3.12 Entering OpenConfirm / Adding "Stop OpenDelay" action 5040 Status: Consensus 5041 Change: Yes 5042 Summary: Add this text: 5044 Change 2 - 5045 Connect state 5046 event 17 (currently defined as going to Active) 5047 event 9 (stays in Connect state) 5049 new Text: 5051 In response to the connect retry timer expires event [Event 5052 9], the local system: 5053 - drops the TCP connection, 5054 - restarts the connect retry timer, 5055 - stops the Open Delay timer and resets the timer to zero, 5056 - initiates a TCP connection to the other BGP peer, 5057 - continues to listen for a connection that may be 5058 initiated by the remote BGP peer, and 5059 - stays in Connect state. 5061 If the TCP connection fails [Event17], the local system: 5062 - restarts the connect retry timer, 5063 - stops the Open Delay timer and resets value to zero, 5064 - continues to listen for a connection that may be 5065 initiated by the remote BGP peer, and 5066 - changes its state to Active. 5068 Further discussion on Keepalives has been moved to issue 52. 5070 Discussion: 5072 This discussion began with Tom outlining these two points: 5074 When the OpenConfirm state is entered from OpenSent with the receipt 5075 of a valid open [Event 18], then a KeepAlive message is sent and the 5076 timer is started. 5078 When the OpenConfirm state is entered from Active or Connect on 5079 receipt of a valid open [Event 19], no message is sent, no timer is 5080 started. 5082 I believe this inconsistency is an error and should be corrected by 5083 adding these two actions in those two places. 5085 Sue replied: 5087 Just to clarify this comment: 5089 Event 19 = valid open with delay timer running 5091 Active = 1) awaiting TCP connection, or 5092 2) TCP connection completed and awaiting the 5093 TCP connection with delay timer running 5095 Case 1: - should not see Event 19 5096 In transition from Active to Open Confirm, the connection 5097 must have a TCP connection completed. Case 1 does not 5098 have this occurring, so the transition must be avoided. 5100 Case 2: - should see Event 19 5102 - Open, Keepalive should be sent. 5104 Previous text: (Action H from FSM document) 5106 If an Open is received with the BGP Delay Open timer running, 5107 [Event 19], the local system: 5108 - clears the connect retry timer [cleared to zero), 5109 - completes the BGP initialization, 5110 - stop and clears the BGP Open Delay timer, 5111 - Sends an Open Message, 5112 - sets the hold timer to a large value (4 minutes), and 5113 - changes its state to an Open Confirm. 5115 New text: [a New Action - N-2 : N + BGP keepalive sent] 5117 If an Open is received with the BGP Delay Open Timer running 5118 [Event 19], the local system: 5119 - clear the connect retry timer [cleared to zero], 5120 - completes the BGP initialization, 5121 - stops and clears the BGP Open Delay timer, 5122 - Send an Open message, 5123 - Sends a Keepalive message, 5124 - If hold timer value is non-zero, 5125 - set keepalive timer 5126 - hold timer reset to negotiated value 5127 else if hold timer is zero, 5128 - reset the keepalive timer, and 5129 - reset the hold timer. 5131 - If the value of the autonomous system field is the 5132 same as the local Autonomous system number, set 5133 the connection status to a internal connection; 5134 otherwise it is "external". 5136 Tom and Sue discussed the OpenDelay state, and recalled that this was 5137 excluded a number of months ago as not reflecting current practice. 5139 By way of clarification, Sue added: 5141 1) Agree, this can occur in the Active state as well as the 5142 Connect state. Will you accept the earlier text below 5143 to be inserted both places? 5145 Background: 5147 The state machine for Event 19 is: 5149 Idle Connect Active Open Open Estb 5150 Sent Confirm 5151 ================================================ 5152 Event 19 | | | | | | | 5153 next state |Idle | Open | Open | Open |Idle | Idle | 5154 | | confirm| confirm| Confirm| | | 5155 ================================================ 5156 action | V | N-2 | N-2 | N | E-1 | E | 5157 ================================================ 5159 Per the State Machine. 5161 Action v - FSM Error 5162 Action E - FSM Error, drop connection - etc, drop routes 5163 Action E-1 - FSM Error, drop connection (lots of 5164 Action N-2 (text below) 5165 Action N (text below, without sending Open) 5167 2) Do you think that Event 19 is possible in the Open Sent state? 5169 Please answer this separately. 5171 Tom replied that: 5173 1) yes I think the same text in both Active and Connect states is a 5174 good resolution 5176 2) complicated. As the fsm text stands, Event 19, along with a 5177 host of others, takes us back from Open Sent to Idle (I assume on 5178 the grounds this is an error condition) which seems very reasonable. 5180 But ...in quite a few places, such as Connect state events 2, 5181 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer 5182 when going to Idle or Active so we could then go from eg Idle with 5183 Manual start [event 1] to Connect to Open Sent all before the 5184 OpenDelay timer expires in which case event 19 can occur validly in 5185 Open Sent - obscure but possible. (This is also true with Active 5186 state and events 2, 17 and the default list at the end). 5188 But I think this is an error, and that when exiting Connect state or 5189 Active state as listed above, we should have an additional action to 5190 stop the OpenDelay timer in which case event 19 in Open Sent becomes 5191 an error condition (again). 5193 But but but as ever, I cannot speak with authority for 5194 implementations and so if implementations do not stop the OpenDelay 5195 timer when exiting as above, then Event 19 is valid in Open Sent 5196 state - obscure but possible (again). 5198 My wish is to add the extra action, stop OpenDelay timer, for the 5199 events listed above in Active and Connect states in the expectation 5200 that that is what people have or should have implemented. 5202 Tom added a response to Sue after some other threads have been 5203 discussed: 5205 You asked if event 19 (Open with OpenDelay timer running) was 5206 possible in OpenSent state; I gave a lengthy reply (below) to the 5207 effect yes it could because the OpenDelay timer did not always get 5208 stopped but the timer should be stopped in which case the event 5209 would not happen. 5211 Reading your responses to Siva , I see you include stopping the Open 5212 Delay timer in the action 'release all BGP resources' when going to 5213 Idle (which I missed seeing earlier in the year). 5215 That eliminates most but not all of the possibilities I mentioned. 5216 I now believe we would need to add the action 'stop OpenDelay timer' 5217 for 5219 Connect state 5220 event 17 (currently defined as going to Active) 5221 event 9 (stays in Connect state) 5223 in order to stop event 19 in Open Sent 5225 Sue replied that, she thought this was at consensus, and provided the 5226 new text, which is: 5228 Change 1: new text 5230 Active state - event 19 5232 If an Open is received with the Open Delay timer is 5233 running [Event 19], the local system 5234 - clears the connect retry timer (cleared to zero), 5235 - stops and clears the Open Delay timer 5236 - completes the BGP initialization, 5237 - stops and clears the Open Delay timer 5238 - sends an OPEN message, 5239 - send a Keepalive message, 5240 - if the hold timer value is non-zero, 5241 - starts the keepalive timer to initial value, 5242 - resets the hold timer to the negotiated value, 5243 else if the hold timer is zero 5244 - resets the keepalive timer (set to zero), 5245 - resets the hold timer to zero. 5247 - changes its state to OpenConfirm. 5249 If the value of the autonomous system field is the same as the 5250 local Autonomous System number, set the connection status to 5251 an internal connection; otherwise it is "external". 5253 Change 2 - 5254 Connect state 5255 event 17 (currently defined as going to Active) 5256 event 9 (stays in Connect state) 5258 new Text: 5260 In response to the connect retry timer expires event [Event 5261 9], the local system: 5262 - drops the TCP connection, 5263 - restarts the connect retry timer, 5264 - stops the Open Delay timer and resets the timer to zero, 5265 - initiates a TCP connection to the other BGP peer, 5266 - continues to listen for a connection that may be 5267 initiated by the remote BGP peer, and 5268 - stays in Connect state. 5270 If the TCP connection fails [Event17], the local system: 5271 - restarts the connect retry timer, 5272 - stops the Open Delay timer and resets value to zero, 5273 - continues to listen for a connection that may be 5274 initiated by the remote BGP peer, and 5275 - changes its state to Active. 5277 Tom replied that: 5279 Change 2, stop Open Delay timer in Connect state events 9 and 17, 5280 fine; that is what I understand to be the real issue 12. 5282 Change 1, event 19 in Active state, is IMHO issues 47 and 52. This 5283 is tangled because the initial paragraphs of Issue 12 in the issue 5284 list are nothing to to with stopping Open Delay timer and everything 5285 to to with sending a Keepalive message before entering Open Confirm 5286 state from Active or Connect state on event 19; which I raised and 5287 see as issue 52. Issue 47 was Siva's issue 28 and relates to a 5288 different action for Active state event 19. 5290 I agree with change 1 in that it adds in the sending of Keepalive 5291 which I believe essential; I think Siva needs to respond concerning 5292 issue 47. (nb the stop Open Delay action is duplicated) I wonder 5293 if we should use a different character for the bullet points under 5294 the if and else clauses to make it clear where they end ie 5295 - if the hold timer .... 5296 + do this 5297 + and this 5298 else if ... 5299 + do the other 5300 + and this 5302 But I still have an issue for Connect state event 19 where I 5303 believe, as for Active state event 19, we should send a Keepalive 5304 and start the Keepalive timer. I will pursue this as part of issue 5305 52 if that suits you. I think the text will be the same as whatever 5306 we agree for Active state event 19. 5308 This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" 5309 thread. And also in the "Event 19 in Open Sent state was Re: bgp18 5310 WG Last Call fsm missing keepalive" thread. This also came up in the 5311 "issues 12 - consensus & two changes - 2nd message" thread. 5313 3.13 FSM Missing Next States 5315 Status: Consensus 5316 Change: Yes 5317 Summary: Seven sub-issues spawned to resolve each of the next-state 5318 questions. See each sub-issue for specifics. 5320 Discussion: 5322 This began with Tom pointing out 7 places where the next state was 5323 not clear. Interlaced with his comments below is the proposed text 5324 to fix the problems and the status of the issue. 5326 All sub-issues are at consensus. 5328 This conversation was started in the "bgp18 WG Last Call fsm missing 5329 next state" thread. 5331 3.13.1 FSM Missing Next States - Event 15 or 16 (Connect State) 5333 Status: Consensus 5334 Change: Yes 5335 Summary: Add next state of Connect. 5337 Discussion: 5339 Tom pointed out that: 5341 Connect State: 5343 If the TCP connection succeeds [Event 15 or 5344 Event 16], the local system checks the "Delay Open 5345 Flag". If the delay Open flag is set, the local system: 5346 **enters what state 5348 Sue proposed these changes: 5350 1) Connect State - Event 15 or Event 16 [consensus, editorial] 5352 note: The delay retry timer is utilized instead of the 5353 connect retry timer for the next two changes. 5355 Previous text: 5357 If the TCP connection succeeds [Event 15 or Event 16], 5358 local system checks the "Delay Open Flag". If the delay 5359 open flag is set, the local system: 5360 - clears the connect retry timer, 5361 - sets the BGP open delay timer to initial value 5363 If the Delay Open flag is not set, the local system: 5364 - clears the connect retry timer, 5365 - clear BGP Open Delay timer (set to zero), 5366 - completes the BGP initialization, 5367 - send an Open message to its peer, 5368 - sets hold timer to a large value, and 5369 - change the state to Open Sent. 5371 New text: 5373 If the TCP connection succeeds [Event 15 or Event 16], 5374 local system checks the Delay Open flag prior to 5375 processing: If the Delay Open flag is set, the local system: 5376 - clears the connect retry timer, 5377 - sets the BGP open delay timer to initial value, and 5378 - stays in the Connect state. 5380 If the Delay Open flag is not set, the local system: 5381 - clears the connect retry timer, 5382 - clears the BGP Delay timer (sets to zero), 5383 - completes the BGP initialization, 5384 - sends an Open message to its peer, 5385 - sets the hold timer to a large value, and 5386 - changes the state to Open Sent. 5388 Tom agreed that this was good, with the change to "Open Delay timer" 5389 as discussed in issue 7. 5391 This conversation was started in the "bgp18 WG Last Call fsm missing 5392 next state" thread. 5394 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: 5523 A TCP connection succeeds [Event 15 or Event 16], 5524 the local system: process the TCP connection flags 5525 - If the BGP delay open flag is set: 5526 - clears the connect retry timer 5528 [through the following text: 5529 - and changes its state to Open Sent. 5531 New text: 5532 If the TCP connection succeeds [Event 15 or Event 16], 5533 local system checks the "Delay Open Flag" prior to 5534 processing: If the delay open flag is set, the local system: 5535 - clears the connect retry timer, 5536 - sets the BGP open delay timer to initial value, and 5537 - stays in the Active state. 5539 If the Delay Open flag is not set, the local system: 5540 - clears the connect retry timer, 5541 - clears the BGP Delay timer (sets to zero), 5542 - completes the BGP initialization, 5543 - sends an Open message to its peer, 5544 - sets the hold timer to a large value, and 5545 - changes the state to Open Sent. 5547 Tom agreed with this. 5549 This conversation was started in the "bgp18 WG Last Call fsm missing 5550 next state" thread. 5552 3.13.4 FSM Missing Next States - Event 13-17 (TCP Connection) 5554 Status: Consensus 5555 Change: Yes 5556 Summary: We selected: 5558 Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17 5559 be mandatory. 5561 Discussion: 5563 Tom started this by saying that: 5565 If the local system receives a valid TCP Indication 5566 [Event 13], the local system processes the TCP connection 5567 flags. 5568 ** 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: 5679 - set TCP disconnect in the MIB reason code, 5680 - restart Connect retry timer (with initial value), 5681 - release all BGP resources, 5682 - Acknowledge the Drop of the TCP connection if TCP 5683 disconnect (FIN ACK), 5684 - Increment ConnectRetryCnt (connect retry count) by 5685 1, and 5686 - performs the BGP peer oscillation damping process. 5688 Applicable FSM State table: 5690 FSM table old: 5692 Event 17 5693 current: Idle Connect Active Open-Sent Open-Confirm Establish 5694 ========================================================= 5695 Next state Idle |Active |Idle |Active | Idle |Idle 5696 | 5697 | | | | | 5698 | 5699 ========================================================= 5700 action V | Y2 | G | Ignore| Track 2nd | Track 2nd 5701 | 5702 | | | | connection | 5703 connection| 5704 ========================================================= 5706 Alternative 1: 5708 FSM table new: 5710 Event 17 5711 current: Idle Connect Active Open-Sent Open-Confirm Establish 5712 ========================================================= 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: 5775 - restarts the connect retry timer (with initial 5776 value, and 5777 - goes to Idle 5779 If the damping process does not allow for a new connection, 5780 the local system 5781 - set the flags to damp the creation of a new bgp 5782 connection until a manual start occurs, and 5783 - goes to Idle. 5785 Tom agreed with the options, and stated that he preferred option 2. 5786 Sue is also happy with option 2, if no one else chimes in. 5788 After the issues list came out Tom responded to this issue, saying: 5790 I think this issue SHOULD be administratively terminated. 5792 It relates to Connect state Event 17 (TCP connection fails) and I am 5793 credited with raising it; in fact, the issue I raised was missing 5794 next state for Active state event 17 and this has now been subsumed 5795 into 13.4 (but note that 13.4 does not explicitly say Active state - 5796 I know it should because I raised that issue too). I will ensure it 5797 does not get lost from any resolution of 13.4. 5799 And Connect state event 17 does appear as part of issue 45 which 5800 Siva raised so I think that either way, 13.5 can go. 5802 This conversation was started in the "bgp18 WG Last Call fsm missing 5803 next state" thread. 5805 3.13.6 FSM Missing Next States - Event 18 (Open Confirm) 5807 Status: Consensus 5808 Change: Yes 5809 Summary: This is the text: 5811 In the Open Confirm state, a valid Open message [Event 22] is 5812 received. The BGP Peer connection is check to see if there is a 5813 collision per section 6.8. If this connection is to be dropped due 5814 to the call collision, the local system will drop the call by: 5816 - sending a NOTIFICATION with a CEASE, 5817 - resets the Connect timer (to zero), 5818 - releases all BGP resources (this includes stopping the Open 5819 Delay Timer 5820 and reseting it to zero), 5821 - increments the ConnectRetryCnt by 1 (connect retry +count), and 5822 - optionally performs a BGP peer oscillation damping processing, 5824 and 5825 - enters the Idle State. 5827 Discussion: 5829 Tom opened this with: 5831 Open Confirm State: 5833 If the Open messages is valid [Event 18], the collision 5834 detect function is processed per section 6.8. If this 5835 connection is to be dropped due to call collision, the 5836 local system: 5837 ** enters what state 5839 Sue replied with: 5841 Here's my proposed text. Please let me know what you think. 5842 I think this is an editorial change. 5844 Old text: If the open message is valid, the collision detect 5845 function is processed per section 6.8. If this 5846 connection is to be dropped due to call collision, the 5847 local system: 5848 - sends a Notification with a Cease 5849 - resets the Connect timer (to zero), 5850 - releases all BGP resources, 5851 - Drop the TCP connection (sends a TCP FIN), 5852 - increments the ConnectRetryCnt by 1 (connect retry 5853 count), and 5854 - performs an BGP peer oscillation damping process. 5856 New text: If the open message is valid, the BGP peer connection 5857 is check to detect a collision per section 6.8. If this 5858 connection is to be dropped due to call collision, the 5859 local system: 5860 - sends a Notification with a Cease 5861 - resets the Connect timer (to zero), 5862 - releases all BGP resources, 5863 - Drop the TCP connection (sends a TCP FIN), 5864 - increments the ConnectRetryCnt by 1 (connect retry 5865 count), and 5866 - performs an BGP peer oscillation damping 5867 processing, 5868 and 5869 - enters the Idle State. 5871 notes: Collision detect impacts Open Sent, Open Confirm, and 5872 Established states. 5874 Tom replied: 5876 I am still struggling with; we are in OpenConfirm so we already have 5877 received an Open from the remote peer and Event 18 is a second Open 5878 from the same peer. Perhaps my struggle is that I think in terms of 5879 two (or more) FSM for a given IP address pair so the Open Collision 5880 detection will occur when the/an- other FSM receives a valid Open in 5881 states Active/Connect/Open Sent and will generate Event 22 into this 5882 FSM so Event 18 cannot occur. But yes, if Event 18 can occur in 5883 this FSM and this connection is to be dumped, then Idle state it 5884 should be as you suggest. I have slotted in [optionally] in front 5885 of the peer oscillation damping in your text because I think it 5886 should be optional:-) 5888 Sue replied: 5890 this mechanism allows a single fsm to 5891 handle both. 2 fsm and 1 fsm BGP FSM 5892 seem to exist. (I queried implementors 5893 a few times on this one. So, I just 5894 put in this change to provide the 5895 flexibility. 5897 Collision detect tends to give 5898 scrambled brains for most people.. 5899 As Dennis Ferguson said 2 years ago, 5900 that's the hardest part of the FSM. 5902 Sue then stated that she would query implementors to see what is 5903 being done. 5905 Sue prodded the list with: 5907 In the Open Confirm state, a valid Open message [Event 22] is 5908 received. The BGP Peer connection is check to see if there is a 5909 collision per section 6.8. If this connection is to be dropped due 5910 to the call collision, the local system will drop the call by: 5912 - sending a NOTIFICATION with a CEASE, 5913 - resets the Connect timer (to zero), 5914 - releases all BGP resources (this includes stopping the Open 5915 Delay Timer 5916 and reseting it to zero), 5917 - increments the ConnectRetryCnt by 1 (connect retry +count), and 5918 - optionally performs a BGP peer oscillation damping processing, 5920 and 5921 - enters the Idle State. 5923 Implementors need to verify if this text and the text for Event 22 5924 allows all implementors to perform the necessary Call Collision 5925 actions. 5927 If no objects, we will use this text. 5929 Curtis said he had no problem with this. 5931 There has been no disagreement, we are at consensus with this. 5933 This conversation was started in the "bgp18 WG Last Call fsm missing 5934 next state" thread. It was also discussed in the "BGP draft-19 - FSM 5935 input needed from developers" thread. 5937 3.14 FSM - Peer Oscillation Damping 5939 Status: Consensus 5940 Change: Yes 5941 Summary: Change references to peer oscillation damping to consistent 5942 phrase: 5943 "[optionally] performs peer oscillation damping". Also remove old 5944 reference to "BGP Peer Restart Backoff Mechanisms". 5946 Discussion: 5948 Tom suggested we use consistent terminology to refer to peer 5949 oscillation damping. He also pointed out a stale reference. 5951 Yakov agreed to fix both of these. 5953 3.15 FSM - Consistent FSM Event Names 5955 Status: Consensus 5956 Change: Yes 5957 Summary: Make FSM names consistent. Specifics are in the discussion 5958 section. 5960 Discussion: 5962 Tom proposed that: 5964 The event name used in the FSM show much variation to the point 5965 sometimes where I am not clear that it is always the same event (eg 5966 where the event name is qualified by a subset of the possible 5967 causes). Assuming that it is, I propose the following changes to 5968 make the wording consistent, clear and concise for event names. 5970 ** denotes changed text using the convention /'old text'/'new text'/ 5972 8. BGP Finite State machine 5974 Event1: Manual start 5975 Event2: Manual stop 5976 Event3: Automatic start 5977 **Event4: Manual start with passive TCP /establishment/flag/ 5978 **Event5: Automatic start with passive TCP 5979 /establishment/flag/ 5980 Event6: Automatic start with bgp_stop_flap option set 5981 **Event7: Auto//matic/ stop 5982 Event8: Idle hold timer expires 5983 Event9: Connect retry timer expires 5984 **Event10: Hold time//r/ expires 5985 Event11: Keepalive timer expires 5986 Event12: Open Delay timer expires 5987 **Event13: TCP connection valid indication 5988 **Event14: TCP connection invalid indication 5989 **Event15: TCP connection request /sent received an 5990 ACK/acknowledged/ 5991 Event16: TCP connection confirmed 5992 Event17: TCP connection fails 5993 Event18: BGPOpen 5994 Event19: BGPOpen with *Open Delay timer running 5995 Event20: BGPHeaderErr 5996 Event21: BGPOpenMsgErr 5997 Event22: Open collision dump 5998 Event23: NotifMsgVerErr 5999 Event24: NotifMsg 6000 Event25: KeepAliveMsg 6001 Event26: UpdateMsg 6002 Event27: UpdateMsgErr 6004 8.2.2 Finite State Machine 6006 Connect State: 6008 If the BGP port receives a ** valid TCP connection 6009 indication 6010 [Event 13], 6012 If the TCP connection receives **an invalid indication 6013 [Event 14]: 6015 If the TCP connection fails **/(timeout or disconnect)// 6017 [Event17] 6019 Active State: 6021 If the local system receives a **valid TCP //indication/ 6022 [Event 13], 6024 If the local system receives a TCP connection failed [Event 6025 17] **/(timeout or receives connection disconnect)//, 6027 Open Sent: 6029 If a connection in Open Sent is determined to be the 6030 connection that must be closed, an **/administrative 6031 collision 6032 detect/Open collision dump/ [Event 22] is signaled to the 6033 state machine. If such an **/administrative collision detect 6034 dump [Event 22]/event/ is 6036 If a TCP **//connection valid/ indication [Event 13] or 6037 TCP **//connection/ request **//acknowledged/ [Event 15] 6039 Open Confirm State: 6041 ...or receives a TCP **/Disconnect// connection fails/ 6042 [Event 6043 17] from the 6045 In the event of **/TCP establishment//TCP connection valid 6046 indication /[Event 13] 6048 ...the local system will 6049 **/issue a call/generate an Open/ collision dump [Event 22]. 6050 When the local system receives a **/call/open/ collision 6051 dump 6052 event [Event 22]/such an event/, the 6054 Established State: 6056 **/disconnect from the underlying TCP/TCP connection fails/ 6057 [Event17], it: 6059 ... it will process **/a Call/an Open/ Collision dump 6060 event[Event 22]. 6062 Notes: 6063 Event 4 title brought in line with text 6064 Event 5 title brought in line with text 6065 Event 7 title brought in line with text 6066 Event 13 title shortened to be closer to text, text brought in line 6067 Event 14 title shortened to be closer to text, text brought in line 6068 Event 15 title brought in line with text 6069 Event 17 text brought in line with title (text often introduces 6070 qualifying conditions that are too restrictive) 6071 Event 22 text brought in line with title 6073 Sue replied: 6075 I will accept the text you proposed for the Event names. 6076 I will update the FSM text to include your changes. 6078 We'll consider issue 15 in consensus. I've fixed the text. 6080 So we are at consensus here. 6082 This is discussed in the thread: "bgp18 WG Last Call fsm event 6083 names." It was also discussed in the "Issue 15 - Consistent FSM 6084 Event Names" thread. 6086 3.16 Many Editorial Comments 6088 Status: Consensus 6089 Change: Yes 6090 Summary: Many editorial suggestions, and what we are doing with them 6091 are listed below. Some issues have been broken out separately where 6092 there is a longer discussion on them. 6094 Discussion: 6096 Alex began this by presenting comments from an anonymous reviewer, 6097 unless otherwise noted, responses are from Yakov: 6099 > Almost all of these are simple clarifications. 6100 > 6101 > Section 1, page 5: IGP definition - it's not clear from this 6102 > definition whether IBGP would be considered an IGP? 6104 any suggestion on how to improve the definition to clarify 6105 this issue would be appreciated. 6107 There was some further discussion on this and it was decided that 6108 people reading this document ought to know what an IGP is. 6110 > Section 3, page 7, para 4: Does RFC 1772 still represent the 6111 > *planned* use of BGP? Or the actual use? Or something 6112 > different from actual use? 6113 Perhaps we should just take out references to 1772. 6115 Further discussion seemed to indicate that this reference should 6116 stay. 6118 > Section 3, page 8, para 3 - "The hosts executing..." This 6119 > paragraph seems obsolete. 6121 I'll take it out. 6123 With regard to this, Siva asked if some route optimization vendors 6124 rely on this. Since this wasn't resolved, it is discussed further in 6125 issue 17. 6127 > Section 4.1, page 11 - Length is in network byte order. 6129 all the encodings are in network byte order. This applies not just 6130 to the BGP spec, but to other protocols as well. 6132 This comment was made about a number of fields. It was later agreed 6133 that a reference would be made to this at the beginning of the 6134 document. 6136 > Section 4.2, page 12 - Hold Time - what does a value of zero 6137 > indicate? 6139 if you read section 4.4 then you'll find that: 6141 If the negotiated Hold Time interval is zero, then periodic 6142 KEEPALIVE messages MUST NOT be sent. 6144 > Section 4.2, page 13 - BGP Identifier - network byte order? 6145 > "IP address" -> "IPv4 address" 6147 I'll put at the beginning a sentence saying that in the context of 6148 this document the term "IP address" means an IP Version 4 address. 6150 > Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> 6151 > "path attributes" 6153 fixed. 6155 > Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address" 6156 > Specify that this is 4 octets. 6157 > Reference here to multi-protocol extensions for IPv6 6158 > nexthop? 6160 no. 6162 > RFC 2283 is unclear whether NEXT_HOP should always be 6163 > included when using multiprotocol extensions. Clarify 6164 > this here? 6166 It is already clarified in 2283bis. 6168 > Section 4.3, Page 17/18 - MED and LocalPref: 6169 > "non-negative" -> "unsigned" for consistency with 6170 > elsewhere. (non-negative might imply values > 2^31 6171 > cannot be used). 6173 fixed. 6175 > Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address" 6176 > Prefix: "enough trailing bits to" -> "the minimum number 6177 > of trailing bits needed to" 6179 fixed. 6181 > Section 4.4, Page 20: - "BGP does not use any TCP-based keep- 6182 alive 6183 > mechanism to determine if peers are reachable". Is it worth 6184 noting 6185 > that TCP may still timeout the connection even if TCP keepalives 6186 are 6187 > turned off? 6189 the text is fine as it is. 6191 > Section 4.4, Page 20: 6192 > KEEPALIVE message consists" -> "A KEEPALIVE message consists" 6194 fixed. 6196 > Section 5, Page 23: "The same attribute can not appear more than 6197 > once with the Path Attributes field...". Does this mean the same 6198 > attribute type, or the same attribute type and value? 6200 the former (the same attribute type). 6202 > Section 5.1 "The usage of each BGP path attributes .." -> 6203 > attribute 6205 fixed. 6207 > Section 5.1.3 "IP address" -> "IPv4 address" 6208 > 6209 > "A BGP speaker must never advertise an address of a peer to that 6210 > peer as a NEXT_HOP, for a route that the speaker is originating." 6211 > suggest replace this text with: 6212 > "A route originated by a BGP speaker must never be advertised to a 6213 > peer using an address of that peer as NEXT_HOP" 6215 fixed. 6217 > Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which 6218 > allows the MULTI_EXIT_DISC to be removed from a route." Might 6219 > want to say that this is dangerous unless you received the route 6220 > from an EBGP peer? 6222 think we should keep the text as is. 6224 > Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE 6225 > message that is received from an external peer, then this 6226 > attribute MUST be ignored by the receiving speaker, except for the 6227 > case of BGP Confederations [RFC3065]." 6228 > - "ignored" might be taken to mean that you don't process it for 6229 > decision, but that you propagate it to internal peers. I might 6230 > write "silently removed" or something similar. 6232 I think the text is ok as is. 6234 > Section 5.1.5, para 2. "set of AS" -> "set of ASs" 6236 fixed. 6238 > Section 6.3: wrt NEXT_HOP semantic correctness: should we check 6239 > that a NEXT_HOP is not a multicast or broadcast address? 6241 I'll add to the definition of NEXT_HOP that it is a unicast address. 6243 > Section 6.3, page 32, para 7: "peer than sent" -> "peer that 6244 > sent" 6246 fixed. 6248 > Section 6.3: "if any attribute appears more than once" - does this 6249 > mean the same attribute type, or the same attribute type and 6250 > value? 6252 the former. 6254 > Section 6.8 "Comparing BGP identifiers is done by treating them as 6255 > (4-octet-long) unsigned integers". Need to convert to host byte 6256 > order before comparing. 6258 fixed. 6260 > Section 6.8, item 2: "closes BGP connection" -> "closes the BGP 6261 > connection"; "accepts BGP connection" -> "accepts the BGP 6262 connection". 6264 fixed. 6266 > Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it 6267 > is unclear for IBGP connections how to determine "the neighbor AS 6268 > from which the other IBGP speaker learned the route". If this is 6269 > really the leftmost entry in the AS path (or the local AS if the 6270 > path is empty), the spec should explicitly say so. 6272 fixed. 6274 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6275 > attribute is removed before..." The first sentence is pretty 6276 > nearly incomprehensible. 6278 This topic has some more discussion surrounding what text we should 6279 use to clarify this issue. This is followed up in issue 18. 6281 > Section 9.1.2.2 (d) 6282 > "d) If at least one of the candidate routes was received from 6283 > an external peer in a neighboring autonomous system, remove 6284 > from consideration all routes which were received from 6285 > internal peers." 6286 > For consistency with (c) and clarity, this might be reworded: 6287 > "d) If any of the candidate routes was learned via EBGP, 6288 > remove from consideration all routes which were learned by 6289 > IBGP." 6291 fixed. 6293 > Section 9.1.2.2 (e) 6294 > "cost (n) is better than cost (m)" 6295 > Given the definition of cost, it might be clearer to say 6296 > "cost (n) is lower than cost (m)" 6298 fixed. 6300 > Section 9.1.2.2 (g) 6301 > "neighbor address" has not been defined. 6303 I'll replace "neighbor address" with "peer address". 6305 > Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes 6306 > of all routes to be aggregated should be ignored." 6307 > 6308 > Perhaps "ignored" is ambiguous here, and it's not clear 6309 > whether should is a SHOULD. Suggest: 6310 > 6311 > "Any AGGREGATOR attributes from the routes to be aggregated 6312 > MUST NOT be included in the aggregated route." 6314 fixed. 6316 > Section 9.3 - shouldn't this subsection be moved to the discussion 6317 > of Phase 1 or Phase 2 of the decision process? Or at least move 6318 it 6319 > before Section 9.2. 6321 I think it is fine where it is now. 6323 > Appendix E, para 2: IP precedence has been deprecated. Delete 6324 > this paragraph, or replace with appropriate diffserv codepoint. 6326 deleted. 6328 > Security Considerations: 6329 > "BGP supports the ability to authenticate BGP messages by using 6330 > BGP authentication." 6331 > This sentence should be removed, and the Authentication 6332 > Information parameter has been deprecated. 6334 Please see the recent e-mail exchange on the Security Considerations 6336 See issue 19 for more on the Security Considerations section of the 6337 draft. 6339 These topics were discussed in the "proxy: more comments on the draft 6340 -18" thread. 6342 3.17 Section 3, Page 8, Paragraph 3 - Obsolete? 6344 Status: Consensus 6345 Change: Yes 6346 Summary: Leave the current definition of BGP Speaker, and normalize 6347 the text to use "BGP Speaker" instead of router. 6349 Discussion: 6351 This issue was spawned from the discussions in issue 16, 6352 specifically: 6354 Anonymous reviewer: 6356 > Section 3, page 8, para 3 - "The hosts executing..." This 6357 > paragraph seems obsolete. 6359 Yakov: 6361 I'll take it out. 6363 With regard to this, Siva asked if some route optimization vendors 6364 rely on this. 6366 Jeff replied: 6368 To provide context, this paragraph currently reads: 6370 : The hosts executing BGP need not be routers. A non-routing host 6371 : could exchange routing information with routers via EGP [RFC904] 6372 : or even an interior routing protocol. That non-routing host could 6373 : then use BGP to exchange routing information with a border router 6374 : in another Autonomous System. The implications and applications 6375 of 6376 : this architecture are for further study. 6378 There are several deployed entities that could be considered to 6379 "exploit" this paragraph. Route collectors, route servers, 6380 bandwidth shapers and other optimizers. However, the original text 6381 may be showing its age a little bit. 6383 Perhaps the following might be a bit more appropriate: 6385 "The hosts executing BGP need not be routers. A non-routing host 6386 may 6387 exchange routing information with a BGP speaker for reasons 6388 that are outside the scope of this document." 6390 I would also propose adding to the same paragraph (but could be 6391 persuaded to drop it since it is *logically* redundant): "These non- 6392 routing hosts should exercise great care not to insert 6393 themselves into the forwarding path if they re-announce BGP 6394 routes." 6396 Yakov replied: 6398 Since operations of non-routing host are outside the scope of the 6399 document, and since the document doesn't preclude non-routing hosts 6400 to run BGP, I would prefer just to take the following paragraph out, 6401 and not to add any new text. 6403 The hosts executing BGP need not be routers. A non-routing host 6404 could exchange routing information with routers via EGP [RFC904] 6405 or even an interior routing protocol. That non-routing host could 6406 then use BGP to exchange routing information with a border router 6407 in another Autonomous System. The implications and applications of 6408 this architecture are for further study. 6410 Jeff replied that this was ok, and instead suggested: 6412 At the beginning of the document, we define: 6413 BGP speaker 6414 A router that implements BGP. 6416 This (potentially) restricts a speaker to being a router. 6417 Additionally, several spots in the text where we probably should 6418 say "BGP speaker", we use router. 6420 Yakov agreed to add this definition. 6422 Jeff replied that there still was a problem with this definition 6423 being too limiting. The discussion meandered off list for a couple 6424 of exchanges and these additional definitions were proposed: 6426 First Jeff proposed this: 6428 "A router that implements the BGP protocol. 6429 Non-routing hosts that also implement BGP are out of scope of this 6430 document." 6432 Then Andrew replied, that we should make sure the definition does not 6433 opt out entirely from making sure that non-routing hosts are 6434 interoperable: 6436 BGP Speaker 6437 A router that implements the BGP protocol. The internal behavior 6438 of non-routing hosts that also implement BGP are out of scope of 6439 this document. However, in their interactions with routers, non- 6440 routing hosts must behave as if they were routers. 6442 And Jeff replied: 6444 BGP Speaker 6445 A router that implements the BGP protocol. The internal behavior 6446 of non-routing hosts that also implement BGP are out of scope of 6447 this document. However, in their interactions with BGP speaking 6448 routers, non-routing hosts that implement BGP should be 6449 indistinguishable from a router on the wire. 6451 (or something like that - s/on the wire/ with whatever sounds best.) 6453 IOW, look like bgp on the wire - what you do internally is out of 6454 scope. 6456 Yakov replied, that we should keep the current definition, since it 6457 is clear that non-routing hosts are outside of the scope. Jeff 6458 responded that he is ok with that if we normalize the use of "BGP 6459 Speaker" instead of "BGP router" in the document. Yakov agreed to 6460 this, we are at consensus on this. 6462 This was discussed in the "proxy: more comments on draft -18" thread. 6463 And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - 6464 Obsolete?" thread. And also, the "issue 17 - final resolution" 6465 thread. 6467 3.18 MED Removal Text 6469 Status: Consensus 6470 Change: Yes 6471 Summary: Use text at the end of the discussion. 6473 Discussion: 6475 This issue is spawned from issue 16. 6477 An anonymous reviewer pointed out: 6479 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC 6480 > attribute is removed before..." The first sentence is pretty 6481 nearly > incomprehensible. 6483 Yakov replied: 6485 here is my attempt to clarify this: 6487 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6488 route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 6489 attribute may only be considered in the comparison of EBGP learned 6490 routes; the attribute is then removed, and then the remaining EBGP 6491 learned routes may be compared to the remaining IBGP learned 6492 routes, without considering the MULTI_EXIT_DISC attribute for those 6493 EBGP learned routes whose MULTI_EXIT_DISC attribute will be removed 6494 before advertising these routes to IBGP. 6496 Any further suggestions on how to improve this would be appreciated. 6498 Siva replied: 6500 How about this: 6502 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6503 route into IBGP, then comparison based on the MULT_EXIT_DISC 6504 attribute may (MUST?) be performed only among the EBGP learned 6505 routes. This comparison MUST be performed before the removal of 6506 the MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must 6507 then be removed from those EBGP routes where such removal is 6508 required and which are still eligible. This is followed by 6509 comparison with IBGP learned routes. 6511 I think this reflects our objectives, which is: 6513 a) If MED is to be removed, compare EBGP routes based on the MED 6515 b) Then remove the MED 6517 c) Then do comparison with IBGP routes 6519 Andrew suggested: 6521 If a router is configured to remove a MULTI_EXIT_DISC attribute from 6522 a route learned from EBGP, before re-advertising it into IBGP the 6523 router MUST compare the route with other EBGP-learned routes before 6524 removing the MULTI_EXIT_DISC. Once this comparison is complete, the 6525 MED may be removed, and any remaining routes can be compared with 6526 IBGP routes to determine the best route. 6528 Yakov replied: 6530 Here is the text that will go in the next version of the draft: 6532 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6533 route into IBGP, then comparison based on the MULT_EXIT_DISC 6534 attribute MAY be performed only among the EBGP learned routes. 6535 This comparison MUST be performed before the removal of the 6536 MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then 6537 removed from those EBGP routes where such removal is required and 6538 which are still eligible. This is followed by comparison with IBGP 6539 learned routes. 6541 Matthew responded to this with: 6543 I think this new text is ambiguous. 6545 >Here is the text that will go in the next version of the draft: 6546 > 6547 > If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6548 > route into IBGP, then comparison based on the MULT_EXIT_DISC 6549 > attribute MAY be performed only among the EBGP learned routes. 6551 This could be taken to mean either that the comparison may be 6552 performed, and if it's performed it must be performed only between 6553 EBGP learned routes, or that the comparison must be performed, but 6554 it may be performed only between EBGP learned routes. 6556 > This comparison MUST be performed before the removal of the 6557 > MULTI_EXIT_DISC attribute. 6559 If doing the comparison is optional, then I think that this sentence 6560 should read "If the comparison is performed, then it MUST be 6561 perfo..." 6563 > The MULT_EXIT_DISC attribute is then 6564 > removed from those EBGP routes where such removal is required and 6565 > which are still eligible. This is followed by comparison with 6566 > IBGP learned routes. 6568 6570 I think that it is desirable for an operator to be able to turn off 6571 MED processing entirely (including turning off all MED based 6572 comparisons), so I would suggest the following text: 6574 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6575 route into IBGP, comparison based on the received MULTI_EXIT_DISC 6576 attribute MAY be performed. If an implementation chooses to 6577 perform this comparison, then the comparison MUST be performed only 6578 among EBGP learned routes, and it MUST be performed before the 6579 removal of the MULTI_EXIT_DISC attribute. 6581 Curtis replied to Yakov's message: 6583 Looks good to me. 6585 I see no need to change "This comparison MUST be performed before 6586 the removal of the MULTI_EXIT_DISC attribute". There is no 6587 implication that MULTI_EXIT_DISC must be removed and the first 6588 sentence clearly indicates that doing so is not required therefore 6589 no ambiguity. Adding a "If a MULTI_EXIT_DISC attribute is removed" 6590 to the second sentence would be redundant. 6592 After some further discussion we have reached full consensus with: 6594 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 6595 route into IBGP, then comparison based on the received EBGP 6596 MULTI_EXIT_DISC attribute MAY still be performed. If an 6597 implementation chooses to remove MULTI_EXIT_DISC, then the optional 6598 comparison on MULTI_EXIT_DISC if performed at all MUST be performed 6599 only among EBGP learned routes. The best EBGP learned route may 6600 then be compared with IBGP learned routes after the removal of the 6601 MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a 6602 subset of EBGP learned routes and the selected "best" EBGP learned 6603 route will not have MULTI_EXIT_DISC removed, then the 6604 MULTI_EXIT_DISC must be used in the comparison with IBGP learned 6605 routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used in 6606 route comparisons which reach this step in the decision process. 6608 This is discussed in the "proxy: more comments on draft 18" thread. 6609 And in the "issue 18" thread. 6611 3.19 Security Considerations 6613 Status: Consensus 6614 Change: Yes 6615 Summary: Fix Security Considerations section to include mandatory MD5 6616 auth 6617 and advance security considerations draft along with the base draft. 6619 Discussion: 6621 Yakov started this discussion by proposing text which would require 6622 TCP MD5 authentication for BGP implementations. This is to bring the 6623 spec in line with an IETF requirement that authentication be 6624 available. 6626 After some discussion the plan is to advance draft-ietf-idr-bgp- 6627 vuln-00.txt as Informational along with the base BGP specification. 6628 This draft will serve as the security analysis section of the base 6629 spec. 6631 This is discussed in the "revised Security Considerations section" 6632 thread. 6634 2.20 Peer Oscillation Damping 6636 Status: Consensus 6637 Change: No 6638 Summary: Keep the Peer Oscillation Damping reference in the 6639 specification. 6641 Discussion: 6643 This began when Siva proposed: 6645 Since this feature is going to be added in a new draft, and its 6646 addition will change the operation of the state machine, can we 6647 remove all mention of it in the state machine ? As part of this 6648 removal, can we also remove the IdleHold Timer from the FSM since it 6649 is not useful in the absence of peer oscillation damping ? 6651 The draft that describes this procedure can then describe the change 6652 in the state machine required to do this. 6654 Sue replied that: 6656 The reason we should not remove the peer oscillation damping 6657 from the state machine: 6659 1) Deployed implementations support peer oscillation damping 6660 2) Hooks for the additions in the FSM cannot be added later. 6662 These hooks are optional and do not need to be implemented. 6664 Siva replied: 6666 I understand. I am not trying to object to peer oscillation 6667 damping, I think it is a good idea and we have included it in 6668 our implementation as well. I was suggesting that instead of 6669 a partial description in this draft, it be completely described 6670 in the draft on peer oscillation damping. 6672 However, I do see your point, and unless there are any objections 6673 from others, I think we have consensus on this issue. 6675 This was discussed in the "Response to FSM input - Comments 1-10" 6676 thread: Comment #1. 6678 3.21 Session Attributes - IdleHold Timer 6680 Status: Consensus 6681 Change: Yes 6682 Summary: Add the text in the discussion section. 6684 Discussion: 6686 This discussion began with Siva asking: 6688 Why have a Hold Timer and a Hold Time ? Can we replace this with 6689 just Hold timer ? 6691 Can we also add the following session attributes: 6693 a) DelayBgpOpenTimer b) IdleHold Timer (in case we choose not to 6694 remove this from the base FSM) 6696 Can we also add the following flag to the session attributes: a) 6697 DelayOpen Flag 6699 After some discussion we have this text on the table: 6701 Event8: Idle hold timer expires 6703 Definition: An Event generated when the Idle Hold Timer 6704 expires. The Idle Hold Timer is only used 6705 when the persistent peer oscillation 6706 damping function is enabled. 6708 % Implementations not implemented persistent 6709 % peer oscillations damping functions may not 6710 % have the Idle Hold Timer. 6712 Sue replied: 6714 I will accept the new text for the following total text: 6716 Event8: Idle hold timer expires 6718 Definition: An event generated when the Idle Hold Timer 6719 expires indicating that the session has 6720 completed a back-off period to prevent bgp peer 6721 oscillation. 6723 The Idle Hold Timer is only used when the 6724 persistent peer oscillation damping function is 6725 enabled. 6727 Implementations not implementing the persistent 6728 peer oscillation damping functions may not have 6729 the Idle Hold Timer. 6731 Status: Optional 6733 We are at consensus with this. 6735 Tom added a couple of minor edits, correcting the spelling of 6736 "persistent" in the third paragraph, and pointing out that: 6738 oscillation damping functions may not have the Idle Hold ** function 6739 ** (because we only have function not functions in the previous 6740 sentence) Timer. 6742 Sue added the edits. 6744 Siva also liked the way this issue has turned out. 6746 This was discussed in the "Response to FSM input - Comments 1-10" 6747 thread: Comment #2. And in the "Draft 19 - issue #21" thread, 6748 alternately the "Draft 19 - Issue 21" thread. 6750 3.22 Specify New Attributes (Accept Connections/Peer Oscillation 6751 Damping) 6753 Status: Consensus 6754 Change: Yes 6755 Summary: Add the text in the discussion section to section 8.0. 6757 Discussion: 6759 This began with Siva proposing: 6761 Can we call these out as well: 6763 * Accept Connections from unconfigured peers (Enabled/Disabled) 6764 * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose 6765 not to remove it from base spec) 6767 After some discussion we have this text on the table: 6769 The following will be added to 8.0 6771 Optional parameters that may be supported either per 6772 connection or per implementation: 6774 1) Delay Open flag 6775 2) Delay Open Timer 6776 3) Perform automatic start flag 6777 4) Passive TCP establishment flag 6778 5) BGP stop_peer_flag flag 6779 6) Idle Hold timer 6780 7) Perform automatic stop flag 6781 8) Perform Collision detect in Establish mode flag 6783 Sue accepted these changes. 6785 Tom added this correction for item 2 in Sue's text: 6787 2) Delay Open Timer 6789 ** Open Delay timer 6790 ** (for which we have consensus in Issue list v2 item 7) 6792 Siva asked, and Sue accepted these additional changes: 6794 9) accept connections from un-configured peers 6795 5) BGP stop_peer_flap flag 6797 We are at consensus on this. 6799 This was discussed in the "Response to FSM input - Comments 1-10" 6800 thread: Comment #3. This was also discussed in the "BGP Draft 19 - 6801 Close open items 22" thread. 6803 2.23 Event1/Event2 Clean Up 6805 Status: Consensus 6806 Change: Yes 6807 Summary: Use "Local system administrator" in both sections. 6809 Discussion: 6811 Siva proposed that we clean up the text for these Events by selecting 6812 either "Administrator" or "Local system" but not both. 6814 Sue proposed text using "Local system administrator" that was agreed 6815 on. 6817 This was discussed in the "Response to FSM input - Comments 1-10" 6818 thread: Comment #4. 6820 2.24 Events 3, 5, 6 & 7 Give Examples 6822 Status: Consensus 6823 Change: No 6824 Summary: Leave the examples out. 6826 Discussion: 6828 This began with Siva proposing we add examples for these event 6829 states. Sue believes this is largely out-of-scope, but did agree to 6830 move the example of "automatic stop" to the event description 6831 section. She asked for proposed text for additional examples. 6833 Sue replied that she has made the following changes, and asked if 6834 these worked for Siva. 6836 New text: 6838 Event7: Automatic stop 6840 Definition: Local system automatically stops the 6841 BGP connection. 6843 An example of an automatic stop event is 6844 exceeding the number of prefixes for a given 6845 peer and the local system automatically 6846 disconnecting the peer. 6848 Status: Optional depending on local system 6850 Siva thought this for Event 7 was fine. 6852 Sue replied to the list, saying that, previously examples had caused 6853 dissension, and asked if there was a strong feeling either way. 6855 Siva proposed this text for Events 3, 5 & 6: 6857 Event 3: 6858 Examples of this event are: 6859 When a connection is terminated during exchange of Open 6860 messages due to version failure 6862 Event 5: 6863 Examples of this event are: 6864 Similar to Event 3 6866 Event 6: 6867 Examples of this event are: 6868 Similar to Event 3 and 6869 b) When a Idle Hold timer expires (within local limit) 6871 Sue replied to this: 6873 I'm going to leave the examples out of events 3, 4, 6 since 6874 I've not heard any strong input on the mail list **and** 6875 I had strong comments on prior versions of the draft. 6877 I'd like to declare that issue 24 has consensus. 6879 Siva agreed, we are at consensus on this issue. 6881 This was discussed in the "Response to FSM input - Comments 1-10" 6882 thread: Comment #5. This was also in the "Issue 25" thread, and the 6883 "Issue 25 - this is really issue 24" threads. This is also in the 6884 "Draft 19 - Issue 24" thread. 6886 3.25 Event 4 & 5 Session Initiation Text 6888 Status: Consensus 6889 Change: No 6890 Summary: Leave the text as is. 6892 Discussion: 6894 This began with Siva wanting to change: 6896 Definition: Local system automatically starts the 6897 BGP session with the passive flag enabled. The 6898 passive flag indicates that the peer will listen prior to 6899 establishing a connection. 6901 to: 6903 The passive flag indicates that the state machine will wait for 6904 specified peer to initiate a connection with the local system. If 6905 this does not happen within a specific time (hold time), the local 6906 system will then also attempt to initiate connection with the 6907 specified peer. 6909 Sue replied: 6911 The text in 8.2.1.1 indicates the definition of the passive flag. 6913 6a) 6914 ========== 6915 My understanding of your text is that you want to replace in both 6916 sets of text: 6918 "The passive flag indicates the peer will listen prior to 6919 establishing a connection". 6921 with: 6923 "The passive flag indicates that the state machine will wait for the 6924 specified peer to initiate a connection with a local system. 6926 The problem with this sentence is that in the "unconfigured" case 6927 the phrase "specified" peer is confusing. I think the original text 6928 is clearer. 6930 6b) 6931 ========== 6932 If this does not happen within a specific time (hold time), the 6933 local system will then also attempt to initiate (a) connection 6934 with the specified peer. 6936 My comments: Again, the "specified peer" term is confusing. Also, 6937 the 2nd half of the statement mixes the actions of the state machine 6938 with the events. I believe this muddies the text instead of 6939 clarifying it. 6941 Siva and Sue later agreed to leave the text the same because of the 6942 Unconfigured + passive TCP connection + Delay Open situation. 6944 This was discussed in the "Response to FSM input - Comments 1-10" 6945 thread: Comment #6. 6947 3.26 Event 4 & 5 - bgp_stop_flap option 6949 Status: Consensus 6950 Change: Yes 6951 Summary: Add new event below. 6953 Discussion: 6955 This began with Siva asking: 6957 Won't a variant of this with bgp_stop_flap option set be required ? 6958 We can also achieve the same by using the bgp_stop-Flap option as a 6959 flag that is provided as an input to the state machine. 6961 Siva later clarified this to include: 6963 We already have 6964 Event 3 - Automatic Start 6965 Event 5 - Automatic start with bgp_stop_flap option set 6966 To make things consistent, shouldn't we either 6968 a) Add 3 new events : 6969 1) Manual start with bgp_stop flap option set 2) 6970 Manual start with passive TCP establishment and 6971 bgp_stop_flap option set 3) Automatic start with 6972 passive TCP establishment and bgp_stop_flap 6973 option set 6975 or 6977 b) Remove Event 6, and rely on a flag to tell us wither peer flap 6978 damping is to be performed for the session or not. 6980 Sue said she preferred option A. And stated that #1 & #2 are 6981 infeasible, but that we need to add #3. 6983 Tom replied: 6985 But if we add an event, then we must add and agree on actions for 6986 all six existing states so I think to say that adding a new event 6987 settle things might be naive. 6989 If we do add 6990 3) Automatic start with passive TCP establishment and bgp_stop_flap 6991 option set 6993 which I understand is Sue's resolution, then for Idle state the 6994 actions are straightforward but for the other five, is the event 6995 completely ignored? If so, does it mean that the passive flag and 6996 the bgp_stop_flap option are ignored and we carry on as if we were 6997 when we were started which may have been without them. Or is the 6998 fact of starting ignored but the flags remain set and so color the 6999 effect of other events? Needs defining. 7001 Jeff replied to this, quoting the existing draft: 7003 The start events [Event 1, 3-6] are ignored in connect 7004 state. 7006 The start events [Event1, 3-6] are ignored in the Active 7007 state. 7009 The Start events [Event1, 3-6] are ignored in the OpenSent 7010 state. 7012 Any start event [Event1, 3-6] is ignored in the OpenConfirm 7013 state. 7015 Any start event (Event 1, 3-6) is ignored in the 7016 Established state. 7018 And elaborated, saying that: 7020 "ignore" means do nothing. This means don't twiddle with the flags. 7021 :-) 7023 The text that was finally agreed on is: 7025 Event 7: Automatic start with bgp_stop flap option set and 7026 passive TCP establishment option set 7028 Definition: Local system automatically starts the 7029 BGP peer connection with peer oscillation 7030 damping enabled and passive TCP establishment 7031 enabled. The exact method of damping persistent 7032 peer oscillations is left up to the 7033 implementation, and is outside the scope of this 7034 document. 7036 Status: Optional, used only if the bgp peer has 7037 enabled bgp peer oscillation damping with 7038 following optional flags settings below. 7040 Optional 7041 attributes: 1) Perform automatic start flag SHOULD be set 7042 2) BGP stop_peer_flap flag SHOULD be set 7044 I've re-ordered the Timer events to keep the text changes 7045 down to a minimum. 7047 action 9 - connect retry timer 7048 action 10 - Hold Timer expires 7049 action 11 - Keepalive timer expires 7050 action 13 - Open Delay timer expires 7051 action 14 - Idle Hold timer expires 7053 All other events are incremented by 1 7055 This was discussed in the "Response to FSM input - Comments 1-10" 7056 thread: Comment #7. 7058 3.27 Event 5 Clarification 7060 Status: Consensus 7061 Change: No 7062 Summary: Leave the text as is. 7064 Discussion: 7066 This began when Siva asked that in event 5: 7068 Is it correct that this event will occur only when we want to 7069 restart a connection (after it had been terminated due to some 7070 reason beside administrative action) that we had accepted from an 7071 unconfigured peer ? 7073 Sue replied: 7075 The automatic start function is an implementation specific 7076 mechanism. This text does not seek to restrict it in any fashion. 7078 Siva said that although he felt his original clarification would be 7079 more useful to new implementors he is ok with the text as is. 7081 This was discussed in the "Response to FSM input - Comments 1-10" 7082 thread: Comment #8. 7084 3.28 Timer Events Definition - Make Consistent 7086 Status: Consensus 7087 Change: Yes 7088 Summary: Change text to use "generate" across the board. 7090 Discussion: 7092 Can we use similar language for Events 8-12 to make them consistent? 7094 It was agreed that we will use "generate" i.e.: 7096 Event 8: An event generated when the Idle Hold timer expires. 7097 Event 9: An event generated when the ConnectRetry timer expires. 7098 Event 10: An event generated when the Hold timer expires. 7099 Event 11: An event generated when the Keepalive timer expires 7100 Event 12: An event generated when the Delay BGP Open timer expires. 7102 This is at consensus. 7104 This was discussed in the "Response to FSM input - Comments 1-10" 7105 thread Comment #9. 7107 3.29 Event 8 - Clean Up 7109 Status: Consensus 7110 Change: Yes 7111 Summary: Clean up first sentence. New text below. 7113 Discussion: 7115 Siva began this by asking if we could clean up the wording of Event 7116 8. 7118 After some discussion with Sue we are at this change for the first 7119 sentence: 7121 An event triggered by the expiry of the Idle Hold timer, indicating 7122 that the session has completed waiting for a back-off period to 7123 prevent bgp peer oscillation. 7125 This was discussed in the "Response to FSM input - Comments 1-10" 7126 thread: Comment #10. 7128 3.30 Hold Timer - Split? 7130 Status: Consensus 7131 Change: No 7132 Summary: Keep the hold timer text as is. 7134 Discussion: 7136 Siva proposed that since: 7138 We use the hold timer for two purposes 7140 * Waiting for an open message (with a default value of 240 seconds) 7141 * Waiting for Keepalives (with a default value of 90 seconds) 7143 Can we use two different timers (or at least call them two different 7144 timer events) ? 7146 Sue replied that this is not how it is implemented currently. Siva 7147 replied that we have two conceptually different timers, but that it 7148 would certainly work to only have one, since only one needs to be 7149 running at any given time. 7151 Tom agreed that we can keep things as is. 7153 This was discussed in the "Comments 11-20" thread: Comment #11. 7155 3.31 OpenDelay Timer Definition 7157 Status: Consensus 7158 Change: Yes - See issue 28 7159 Summary: This is fixed by the fixing of issue 28. 7161 Discussion: 7163 This began with Siva's request that we add something to Event 12 to 7164 specify what to do when the timer expires. This seems to have been 7165 addressed in issue 28. 7167 This was discussed in the "Comments 11-20" thread: Comment #12. 7169 3.32 Definition of TCP Connection Accept (Event 13) 7171 Status: Consensus 7172 Change: Yes 7173 Summary: Change "Definition" text as indicated below. 7175 Discussion: 7177 Siva proposed that we change text from referring to "TCP connection 7178 request" to "receiving a TCP connection". This led to this proposed 7179 text: 7181 Definition: Event indicating the reception of a TCP 7182 connection 7183 request with a valid source IP address and TCP 7184 port, and valid destination IP address and 7185 TCP Port. The definition of invalid source 7186 address and port and invalid destination address 7187 is left to the implementation. 7189 This met with agreement. 7191 This thread also discussed the idea of filtering the incoming 7192 address/port. It was decided that this was implementation dependent. 7194 This was discussed in the "Comments 11-20" thread: Comment #13. 7196 3.33 Event 13 & 14 - Valid Addresses & Ports 7198 Status: Consensus 7199 Change: Yes 7200 Summary: See text at the end of the discussion. 7202 Discussion: 7204 With regard to Event 13 & 14, Siva raised questions about: 1) What 7205 does it mean to validate a port, and 2) Should we state what we 7206 consider an invalid IP address to be? 7208 Sue replied that this is local policy and is implementation 7209 dependent. Siva agreed regarding the source port & IP address, but 7210 disagreed about the destination port. He argued that we need to know 7211 the destination port for interoperability. 7213 Sue asked Siva to provide some text. 7215 After a long lull, Sue replied with: 7217 I would like to keep the current text of 7218 "Should" in the following text 7220 "BGP's destination port SHOULD be port 179 7221 as defined by IANA." 7223 Should indicates that it normally should 7224 be 179. If an implementation allows for 7225 an alternative TCP port, it is still valid as the 7226 "MUST" is not indicated. 7228 There have been no further comments on this, the chairs have decided 7229 to close it. 7231 This was discussed in the "Comments 11-20" thread: Comment #14. This 7232 was also in the "BGP-19: Issue 33" thread. 7234 3.34 Event 17 - TCP Connection Fails to TCP Connection Termination 7236 Status: Consensus 7237 Change: Yes 7238 Summary: Change the text to "fails." 7240 Discussion: 7242 This began with Siva observing: 7244 This event can occur even when the transport connection is closed by 7245 the other end. Since this does not reflect a 'failure ', can we 7246 change the event name to 7248 % Event17: TCP connection termination 7250 Sue replied that: 7252 Discussion: It both terminates from the remote site 7253 and can "timeout" - fail. 7255 Suggestions? I can use "disconnect", what do you think. 7257 Siva replied that this was a minor issue, and on further reflection, 7258 either "fails" or "disconnect" would be acceptable. 7260 Sue replied that she has accepted Siva's comments, and the text will 7261 be changed to "fails". 7263 This was discussed in the "Comments 11-20" thread: Comment #15. This 7264 was also discussed in the "BGP-19: Issue 34-35, 40-48" thread. 7266 3.35 Making Definition Style Consistent 7268 Status: Consensus 7269 Change: Yes 7270 Summary: Adopt consistent style for the definition of events. 7272 Discussion: 7274 This started with Siva asking if we could make the definition style 7275 consistent across events. Sue replied to this with text for 13-17, 7276 Siva clarified that he was talking more about 18-21, and proposed 7277 text. 7279 We are agreed on the text for 13-17: 7281 Event13: TCP connection indication and valid remote peer 7283 Definition: Event indicating the local system reception 7284 of a TCP connection request with a valid source 7285 IP address and TCP port, and valid destination 7286 IP address and TCP Port. The definition of 7287 invalid source, and invalid destination IP 7288 address is left to the implementation. 7290 BGP's destination port SHOULD be port 179 as 7291 defined by IANA. 7293 TCP connection request is denoted by the local 7294 system receiving a TCP SYN. 7296 Status: Mandatory (Optional) 7298 Event14: RCV TCP connection indication with invalid source or 7299 destination 7301 Definition: Event indicating the local system reception 7302 of a TCP connection request with either 7303 an invalid source address or port 7304 number or an invalid destination 7305 address or port number. 7307 BGP destination port number SHOULD be 179 7308 as defined by IANA. 7310 Again, a TCP connection request 7311 denoted by local system receiving a TCP 7312 SYN. 7314 Status: Mandatory (Optional) 7316 Event15: TCP connection request sent received an ACK. 7318 Definition: Event indicating the Local system's request 7319 to establish a TCP connection to the remote 7320 peer. 7322 The local system's TCP session sent a TCP 7323 SYN, and received a TCP SYN, ACK pair of 7324 messages, and Sent a TCP ACK. 7326 Status: Mandatory 7328 Event16: TCP connection confirmed 7330 Definition: Event indicates that the local system 7331 receiving a confirmation that the TCP 7332 connection has been established by the 7333 remote site. 7335 The remote peer's TCP engine sent a TCP SYN. 7336 The local peer's TCP engine sent a SYN, ACK 7337 pair, and now has received a final ACK. 7339 Status: Mandatory 7341 Event17: TCP connection fails 7343 Definition: Event indicates that the local system has 7344 received a TCP connection failure notice. 7346 The remote BGP peer's TCP machine could have 7347 sent a FIN. The local peer would respond 7348 with a FIN-ACK. Another alternative is that 7349 the local peer indicated a timeout in the 7350 TCP session and downed the connection. 7352 Status: Mandatory 7354 Siva proposed these changes for 18-21: 7356 Event18: BGPOpen 7358 Definition: An event indicating that a valid Open 7359 message has been received. 7361 with 7363 Event18: BGPOpen 7365 Definition: An event is generated when a valid Open 7366 message has been received. 7368 Event19: BGPOpen with BGP Delay Open Timer running 7369 Definition: An event indicating that a valid Open 7370 message has been successful 7371 established for a peer that is 7372 currently delaying the sending of an 7373 BGP Open message. 7375 with 7377 Event19: BGPOpen with BGP Open Delay Timer running 7379 Definition: An event is generated when a valid Open 7380 message has been received for a peer that 7381 is currently delaying the sending of a 7382 BGP Open message. 7384 Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer" 7385 per issue 7. 7387 Event20: BGPHeaderErr 7389 Definition: BGP message header is not valid. 7391 with 7393 Event20: BGPHeaderErr 7395 Definition: An event is generated when a received BGP 7396 message header is not valid. 7398 Event21: BGPOpenMsgErr 7400 Definition: An BGP Open message has been received 7401 with errors. 7403 with 7405 Event21: BGPOpenMsgErr 7407 Definition: An event is generated when BGP Open message 7408 with errors has been received. 7410 Sue replied that she accepted Siva's comments, so we are at consensus 7411 here. 7413 This was discussed in the "Comments 11-20" thread: Comment #16. This 7414 also came up in the "BGP-19: Issue 34-35, 40-48" thread. 7416 3.36 Event 19 - Definition Cleanup 7417 Status: Consensus 7418 Change: Yes 7419 Summary: Replace definition for Event 19 with the text in the 7420 discussion. 7422 Discussion: 7424 Siva proposed we replace: 7426 Definition: An event indicating that a valid Open Message has been 7427 successful established for a peer that is currently delaying the 7428 sending of an BGP Open message. 7430 with: 7432 Definition: An event indicating that a valid OPEN Message has been 7433 received for a peer that has a successfully established transport 7434 connection and is currently delaying the sending of a BGP open 7435 message 7437 in Event 19. Sue agreed to the changes. 7439 This was discussed in the "Comments 11-20" thread: Comment #17. 7441 3.37 Event 22 - Cleanup 7443 Status: Consensus 7444 Change: Yes 7445 Summary: Replace Event 22 definition with the text from the 7446 discussion. 7448 Discussion: 7450 Siva began with observing: 7452 Event22: Open collision discard 7454 Definition: An event generated administratively 7455 when a connection Collision has been 7456 detected while processing an incoming 7457 Open message. This connection has been 7459 Isn't this event 'automatically' generated, since it is a system 7460 generated event ? 7462 Sue replied that: 7464 response: How this generated is implementation specific. The 7465 "administratively" is to cover policy. 7467 Siva also proposed an editorial fix with: 7469 Event 22 is an administrative could 7470 occur if FSM is implemented as two 7472 The word event is missing. How about 7474 Event 22 is an automatic event that 7475 could occur if FSM is implemented as two 7477 Sue replied with this rewritten text: 7479 Event22: Open collision dump 7481 Definition: An event generated administratively 7482 when a connection collision has been 7483 detected while processing an incoming 7484 OPEN message and this connection has been 7485 selected to disconnected. See Section 7486 6.8 for more information on collision 7487 detection. 7489 Event22 is an administrative based only 7490 implementation specific policy. This 7491 Event may occur if the FSM is implemented 7492 as two linked state machines. 7494 Siva agreed with this new text. 7496 This was discussed in the "Comments 11-20" thread: Comment #18. 7498 3.38 FSM Description - ConnectRetry Count 7500 Status: Consensus 7501 Change: No 7502 Summary: Leave the counter text alone, since it is used in peer 7503 oscillation and will be in the MIB. 7505 Discussion: 7507 Siva opened with this question: 7509 The Connect Retry count is updated by the FSM but never used. In the 7510 absence of peer oscillation damping, will this be used to stop 7511 connection establishment attempts after a certain maximum number ? 7513 7514 Yes, this is either implementation specific or 7515 is it based on the peer oscillation damping draft. 7517 Can we include the use of this counter in some place ? 7519 7520 Connect retry counter 7521 1) Will be utilized by the peer oscillation damping 7522 draft. 7523 2) Will be included in bgp-4-mibv2-xx. 7524 I just check and I didn't find it. 7526 Do you still want text in the main? 7528 To which Siva replied that he believes we can leave the main text 7529 alone. 7531 This was discussed in the "Comments 11-20" thread: Comment #19. 7533 3.39 Handling Event 7 (Auto Stop) to Idle State processing 7535 Status: Consensus 7536 Change: Yes 7537 Summary: Fix the text as indicated in the discussion. 7539 Discussion: 7541 Siva began with: 7543 The handling of Event 7 is missing from the Idle State processing. 7544 Can we add this ? How about replacing 7546 An manual stop event (Event2) is ignored in the Idle state. 7548 with 7550 Manual stop (Event 2) and Auto stop (Event 7) events are ignored 7551 in the Idle state 7553 Sue replied that she would add the text. 7555 This was discussed in the "Comments 11-20" thread: Comment #20. 7557 3.40 Clearing the Connection Retry Timer 7558 Status: Consensus 7559 Change: No 7560 Summary: Leave things alone, since it is better to be redundant than 7561 to let something slip through. 7563 Discussion: 7565 Siva opened with the observation: 7567 There are a few sections where the FSM draft states that the 7568 Connection Retry timer needs to be reset, whereas the connect retry 7569 timer had been cleared prior to entering that state. We can remove 7570 these instructions to clear the connect retry timer. 7572 List of places where the connect retry timer need not be cleared 7574 a) Handling of Event 19 in the Connect State 7575 b) Handling of Events 12 in the Active State 7576 c) All cases where it is referred to in the OpenSent, 7577 OpenConfirm and Established states 7579 Sue replied: 7581 Comment: 7582 1) Does it hurt to have the connect retry timer cleared 7583 at these points, since it has already been cleared. 7585 I felt it eased the implementations to allow the action 7586 routines to be shared across as many states as possible. 7587 You can see this a bit more actively. 7589 Tom replied to this: 7591 I propose we leave it in and close this issue. 7593 1) To take out an action as redundant you need to be supremely 7594 confident that it really cannot make a difference. I am not 7595 (supremely confident); rather, the more I look at the FSM, the more 7596 places I find where actions are missing, as I have posted to the 7597 list, from obscure yet possible sequences of events and timing. And 7598 there is an outstanding issue of mine which flagged seven places 7599 where the next state was missing and so I think it impossible for 7600 any one to be confident that any particular action is redundant 7601 until that is cleared up and that is proving complex in some cases. 7602 So, play safe, keep them in. 7604 2) The argument for removing them is that the number of possible 7605 distinct action lists is increased. True - it will mean that an 7606 implementor will have to code more code when first implementing BGP. 7608 For me this is no contest; keeping it safe at the possible cost of 7609 redundancy outweighs the one-off cost of additional implementation. 7611 So keep the actions in and close the issue. 7613 Jeff replied that he agreed with Tom on this. 7615 Siva concurred, that this approach was acceptable. 7617 Unless someone objects, this issue is at consensus. 7619 This was discussed in the "Comments 21-30" thread: Comment #21. This 7620 is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry 7621 timer" thread. 7623 3.41 Handling of Event 14 in the Connect State 7625 Status: Consensus 7626 Change: Yes 7627 Summary: Make event 14 optional. 7629 Discussion: 7631 Siva opened the discussion with: 7633 > If the transport connection receives an indication 7634 > that is invalid or unconfigured. [Event 14]: 7635 > - the TCP connection is rejected. 7637 I don't understand how we would get this event while in this state. 7639 Sue replied: 7641 See my earlier comments (1-10) on the connection state. 7642 It happens in implementations which track the TCP state more 7643 closely. I suggest that Event 14 become optional. 7645 Sue also suggested we fold this into the discussion about events 7646 13-17, which is tracked in issue 13.4. 7648 Sue proposed: 7650 My resolution: Let event 14 be optional. 7651 Not all BGP implementations support it. 7653 And asked if this let us reach consensus on this issue. 7655 Siva agreed with this, we are at consensus on this. 7657 This was discussed in the "Comments 21-30" thread: Comment #22. This 7658 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 7660 3.42 Handling events 20, 21 in the Connect State and Active State 7662 Status: Consensus 7663 Change: Yes 7664 Summary: Use the text Tom proposed in the discussion section. 7666 Discussion: 7668 Siva began this with: 7670 We need to consider the case where we receive events 20 (message 7671 header error) and 21 (Open message error) when the delay timer is 7672 running. 7674 Since the connection has been established at this point, we need to 7675 send a Notification message and then terminate the connection. 7677 To which Sue replied: 7679 Alternative comments: 7681 1) We have not sent an Open statement. 7682 2) Why do we have to send an Notification? I see no justification 7683 for it. 7685 Suggestion: 7686 Do you have implementations that send notification? Do 7687 you know of others that don't. 7689 Jeff saw this as indicative of an issue with section 4.2 the way it 7690 is currently written: 7692 >From section 4.2 of -18: 7693 4.2 OPEN Message Format 7695 After a TCP is established, the first message sent by each side 7696 is an OPEN message. If the OPEN message is acceptable, a 7697 KEEPALIVE message confirming the OPEN is sent back. Once the OPEN 7698 is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be 7699 exchanged. 7701 This text implies that NOTIFICATIONs can only be sent once we 7702 have sent an open and then a keepalive, generally meaning we're 7703 in the Established state. 7705 Anyone suggestions for modifying the wording? 7707 Section 6.1 (Message header error) is one situation that implies 7708 that a NOTIFICATION can be sent without sending even an OPEN 7709 message. Note that since the base FSM implies that we send an 7710 OPEN message immediately when we have a completed transport 7711 connection, we SHOULD be in at least OpenSent. However, the 7712 DelayOpen timer means that we MAY send a NOTIFICATION when we are 7713 in the Connect state. 7715 GateD, at least, will not send a NOTIFICATION without first 7716 sending an OPEN. 7718 We need to pick one: You can send NOTIFICATIONS before OPEN or 7719 before OPEN if the OpenDelay timer is running. However, we MUST 7720 fix the text above. 7722 Tom opined: 7724 A NOTIFICATION without a preceding OPEN is rather hard to interpret; 7725 it is the OPEN that gives the recipient what it needs to know about 7726 its potential peer (Version, AS number, ID, options etc) so it makes 7727 sense to send an OPEN even if it is followed by a NOTIFICATION to 7728 say goodbye :-( as opposed to a KEEPALIVE which says hello:-). 7730 But as ever, what is implemented? 7732 Yakov suggested these modifications to the text to resolve this: 7734 1. Delete the last sentence in the above paragraph 7736 or 7738 2. Delete "and NOTIFICATION" in the last sentence in the above 7739 paragraph 7741 Jeff replied that he preferred the first option, and that the second 7742 could be interpreted as NOTIFICATIONs not being legal, when, in fact, 7743 they may. 7745 So the text on the table to resolve this is: 7747 4.2 OPEN Message Format 7749 After a TCP is established, the first message sent by each side 7750 is an OPEN message. If the OPEN message is acceptable, a 7751 KEEPALIVE message confirming the OPEN is sent back. 7753 However, this does not entirely clear up the original point about the 7754 FSM. If we receive an error in Connect/Active, do we send a NOTIFY? 7755 Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in 7756 immediate succession? 7758 Sue replied: 7760 I suggest we don't send a "NOTIFICATION" when Event 20 or Event 21 7761 is received in Connect or Active state. 7763 Tom responded to this issue with: 7765 Issue 42 queries whether or not we can send a NOTIFICATION when we 7766 have not successfully exchanged OPENs. I propose we should, 7767 following the suggestions of Jeff and Yakov. 7769 As Yakov suggested, this requires the removal of the second 7770 sentence, first paragraph, of 4.2 which implies a NOTIFICATION can 7771 only be sent after a successful exchange of OPENs. I think this 7772 fits best with the other references to the uses of NOTIFICATION in 7773 the draft. 7775 In terms of the FSM, it means that in Connect and Active states, on 7776 receipt of events 20 or 21, we should send a NOTIFICATION so that 7777 the last section starting 7779 In response to any other event............. 7781 is replaced by (and noting we have agreed to drop references to MIB 7782 actions) 7784 If the BGP message header checking or OPEN message 7785 checking detect an error (see Section 6.2) [Events 20 or 21], 7786 the local system: 7787 - sends a NOTIFICATION message with the appropriate 7788 error code, 7789 - resets the connect retry timer (sets to zero), 7790 - releases all BGP resources, 7791 - drops the TCP connection 7792 - increments the ConnectRetryCnt (connect retry count) 7793 by 1, 7794 - [optionally] performs peer oscillation damping 7795 - and goes to the Idle state. 7797 In response to any other event (Events 7-8, 10-11,18, 22-27), the 7798 local system: 7800 - resets the connect retry timer (sets to zero), 7801 - releases all BGP resources, 7802 - drops the TCP connection, 7803 - increments the ConnectRetryCnt (connect retry count) 7804 by one, 7805 - [optionally] performs peer oscillation damping, 7806 - and goes to the Idle state 7808 (Note that this text is not quite watertight. Suppose we are in 7809 Active state, having been started with CRT running, receive an SYN 7810 (event 13), send SYN-ACK and then get a malformed message (events 7811 20/21). We have not yet received an ACK and so should not send 7812 anything over TCP; I would expect TCP to buffer this awaiting the 7813 ACK except we then take down the TCP connection - or try to; I don't 7814 know what happens next but regard it as sufficiently obscure not to 7815 be concerned). 7817 (My other concern is greater; why do we now not send NOTIFICATIONs 7818 for other events; in Open Sent, Open Confirm or Established, we send 7819 one for the 'default event list' so what makes events 20 and 21 in 7820 Active and Connect so special? I can justify the absence of a 7821 NOTIFICATION for events 7, 8, 10, 11, 18, 22 since there is no 7822 evidence of a TCP connection to send it on; but events 23-27 in 7823 Active or Connect say we have received an erroneous message, the TCP 7824 connection is there so why not send a NOTIFICATION? 7825 Event7: Automatic stop 7826 Event8: Idle hold timer expires 7827 Event10: Hold timer expires 7828 Event11: Keepalive timer expires 7829 Event18: BGPOpen 7830 Event22: Open collision dump 7831 Event23: NotifMsgVerErr 7832 Event24: NotifMsg 7833 Event25: KeepAliveMsg 7834 Event26: UpdateMsg 7835 Event27: UpdateMsgErr 7837 Sue accepted Tom's text, so barring any objections, we are at 7838 consensus on this. 7840 This was discussed in the "Comments 21-30" thread: Comment #23. This 7841 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and 7842 the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread. 7844 3.43 Handling the default events in the Connect state 7846 Status: No Consensus 7847 Change: Potentially 7848 Summary: Add text at the end of the discussion. 7850 Discussion: 7852 Siva opened this with: 7854 The Open Delay timer [original: BGP Delay Open Timers) needs to be 7855 cleared if it is running. 7857 How about adding this: 7859 % - If the ConnectRetry Timer is running 7860 % - Clear the Connect Retry timer 7861 % - Otherwise 7862 % - Clear the Open Delay timer [original: BGP Delay Open Timer] 7864 Sue replied that: 7866 By the default you mean the text: 7868 In response to any other events[Events 7-8, 10-11, 18, 7869 20-27], the local system: 7871 "resets" to me implies stops and clears. I think the 7872 text is clear than the text above. 7873 ------------ 7874 Is this the replacement text you imply above: 7875 - resets the connect retry timer (sets to zero), 7876 - clears the Open Delay timer [original: BGP Delay timer] (sets to 7877 zero), 7878 - increments the ConnectRetryCnt (connect retry count) by 1, 7879 - [optionally] performs bgp peer oscillation damping, and 7880 - goes to Idle text: 7882 Editor's note: various incarnations of "Open Delay timer" have been 7883 replaced with "Open Delay timer". See issue 7. 7885 Sue replied that she accepted Siva's changes with these editorial 7886 changes: 7888 old text: 7889 - resets the connect retry timer (sets to zero) 7890 - clears the open delay timer 7892 new text: 7893 - if the connect retry timer is running, 7894 clear the connect retry timer (set to zero). 7895 - if the open delay timer is running, 7896 clear the open delay timer (set to zero). 7898 Since the substantive changes have been accepted, unless someone 7899 objects, this issue is at consensus. 7901 This was discussed in the "Comments 21-30" thread: Comment #24. This 7902 was also brought up in the "BGP-19: Issue 34-35, 40-48" 7904 3.44 Handling Event 23 in Connect and OpenSent 7906 Status: Consensus 7907 Change: Yes 7908 Summary: Adopt text at the end of the discussion section. 7910 Discussion: 7912 This began with Siva saying: 7914 This is currently being handled in the default event processing 7915 section. However, we do not need to go through the peer oscillation 7916 damping process in this case. Can we change the wordings to reflect 7917 this, or move this out of peer oscillation damping processing ? 7919 Sue replied: 7921 1) There is no default event handling process in the text, you 7922 will need to specify the text. 7924 2) The state table below (hares-statemt-03.txt) states shows 7925 the changes 7927 ------------- 7928 Event 23 7929 states: 7930 current Idle Connect Active Open-Sent Open-Cnf Establish 7931 ------------------------------------------------- 7932 next state Idle Idle Idle Idle Idle Idle 7933 ------------------------------------------------- 7934 action V D D Y Y T 7935 ================================================= 7937 V - Indicate FSM errors and ignore. D - 1) resets the connect retry 7938 timer (sets to zero), 7939 2) drops the TCP connection, 7940 2) releases all BGP resources, 7941 3) increments the ConnectRetryCnt (connect retry count) by 1, 7942 4) [optionally] performs the bgp peer oscillation damping, and 7943 Goes to Idle state. 7945 Y 1) resets the connect retry timer (sets to zero), 7946 2) Drops the TCP connection, 7947 3) releases all BGP resources, 7948 4) [optionally] 7950 In an exchange between Siva and Sue, this came up: 7952 Siva: 7954 "Default event handling" was perhaps a poor choice of words. 7956 What I meant is this 7958 Event 23 (Notify Message Version error) only indicates a version 7959 mismatch. By going through action sequence D, we will be performing 7960 peer oscillation damping. Should we perform damping, since this is 7961 not really a cause for persistent oscillation ? 7963 Also, since we have a distinct event to indicate a version error 7964 event, can include text indicating that version negotiation 7965 processing should take place upon receipt of this event ? 7967 Sue: 7969 Yes, we can change the "D" in state machine to a "y". 7971 The issue is what if Connect state occurs and there is not 7972 a TCP connection. Should an OPEN with wrong version 7973 be accepted? If the Open Delay flag is off, the connection 7974 state should not be getting an Open. The "D" action below 7975 works for "open delay flag off". 7977 The "y" action you suggest can occur if the open delay 7978 timer is on. 7980 If this is the issue, please confirm. 7982 We could say: if open delay flag is on -> y action 7983 if open delay flag is off -> D action 7985 Please let me know if this is the concern, and suggest 7986 text. 7988 Prior to this exchange, this issue was at consensus. The only thing 7989 that is firm in this exchange is changing "D" to "y". There seems to 7990 be some open discussion still, so we'll reopen it. 7992 After some discussion, this is the text we have settled on: 7994 If a NOTIFICATION message is received with a version 7995 error[Event24], the local system checks the Open Delay timer. 7996 If the Open Delay timer is running, the local system: 7997 - resets the connect retry timer (sets to zero), 7998 - stops and reset the Open Delay timer (sets to zero, 7999 - releases all BGP resources, 8000 - drops the TCP connection, 8001 - changes its state to Idle. 8002 If the Open Delay timer is not running, the local system: 8003 - resets the connect retry timer (sets to zero), 8004 - releases all BGP resources, 8005 - drops the TCP connection, 8006 - increments the ConnectRetryCnt (connect retry count) by 1, 8007 - optionally performs peer oscillation damping, and 8008 - changes its state to Idle. 8010 N.B. This is now event 24 (see issue 26). 8012 We are at consensus with this. 8014 This was discussed in the "Comments 21-30" thread: Comment #25. This 8015 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 8017 3.45 Event 17 in the Connect state 8019 Status: Consensus 8020 Change: Yes 8021 Summary: Adopt text at the end of the discussion section. 8023 Discussion: 8025 This began with Siva asking: 8027 If the transport connection fails (timeout or transport 8028 disconnect) [Event17], the local system: 8029 - changes its state to Active. 8031 If the transport connection fails when the Open Delay timer 8032 [original: BGP Open Delay timer] is running, should we still be 8033 going into the Active state ? 8035 Sue replied referring to the discussion tracked in issue 13.4. 8037 Jeff responded that: 8039 In this particular case, I think the issue is separate from the 8040 issues for events 13-17 since this isn't particular to how deep the 8041 BGP implementation meddles in the TCP implementation. 8043 If we are in the Connect state, because we have an incoming 8044 transport connection that has completed, but we have the OpenDelay 8045 timer running and the transport connection is closed, we can simply 8046 drop into Active after resetting the ConnectRetry timer and clearing 8047 the OpenDelay timer (if set/exists). In the case of an unconfigured 8048 peer, we can discard the FSM instance. 8050 Tom replied that he agreed with this. 8052 Tom then proposed this text: 8054 If the TCP connection fails[Event 17] and the Open Delay 8055 timer is running, the local system: 8056 - restarts the connect retry timer, 8057 - clears the Open Delay timer 8058 - continues to listen for a connection that may be 8059 initiated by the remote BGP peer, and 8060 - changes its state to Active. 8062 If the TCP connection fails [Event17] and the Open Delay 8063 timer is not running, the local system: 8064 - drops the TCP connection, 8065 - releases all BGP resources, 8066 - sets ConnectRetryCnt (the connect retry count) to zero 8067 - resets the connect retry timer (sets to zero), and 8068 - goes to Idle state. 8070 to replace 8072 If the TCP connection fails (timeout or disconnect) 8073 [Event17], the local system: 8074 - restarts the connect retry timer, 8075 - continues to listen for a connection that may be 8076 initiated by the remote BGP peer, and 8077 - changes its state to Active. 8079 Sue agreed to change the text to reflect the comments. 8081 Jeff brought out a couple of other concerns, and Tom replied: 8083 > If the TCP connection fails [Event17] and the Open Delay 8084 > timer is not running, the local system: 8085 > - drops the TCP connection, 8086 > - releases all BGP resources, 8088 There are no resources to release while in the connect state. 8089 (Unless we're using this as shorthand for something else - I 8090 forget.) 8092 Tom: 8094 I was unsure about this action. It is present for Active state 8095 event 17 which is why I put it in, it does include sub-actions such 8096 as clear Open Delay timer (not running), clear Connect Retry timer 8097 (could be running) so I think it right to play safe and include it. 8099 Jeff: 8101 > - sets ConnectRetryCnt (the connect retry count) to zero 8103 I'm forgetting if this action is consistent with everything else. 8104 I don't have a current copy of the FSM and I don't trust -18 to be 8105 current enough. :-) 8107 This said, why do we go to zero? I could see not incrementing it 8108 and letting the normal decay process deal with it. The same would 8109 apply for the above. 8111 Tom: 8113 Again, I was unsure about this so put it in and waited for comment. 8114 I have a chart of 27 events and 6 states in which I have colored in 8115 the connect retry and peer oscillation damping actions and it looks 8116 like measles; I could not divine the underlying logic. Incrementing 8117 the connect retry count would make as much if not more sense to me. 8118 (It is zeroed for Manual Stop). 8120 But the action '[optionally] perform peer oscillation damping' is 8121 yet more erratic (eg for event 10 - Hold Timer expired - it is 8122 performed exiting Connect, Active, Established but not Open Confirm 8123 or Open Sent) so I left it out. Again, it might make more sense put 8124 it in. 8126 Sue replied to this: 8128 The connect state could have a few resources 8129 (minimum peer footprint) as the FSM goes 8130 from Idle to Connected state. While this amount 8131 of BGP resources is not as much as the final 8132 amount, it still needs to get released. 8134 2nd - I think the ConnectRetry count should be removed; 8135 Thanks for catching that. 8137 Please confirm that part #1 is OK with you so we can 8138 put issue 45 into consensus state. 8140 Sue accepted Tom's solution, for the following text: 8142 If the TCP connection fails [Event18], the local system checks 8143 the Open Delay Timer. If the Open Delay timer is running, 8144 the local system: 8145 - restarts the connect retry timer, 8146 - stops the Open Delay timer and resets value to zero, 8147 - continues to listen for a connection that may be 8148 initiated by the remote BGP peer, and 8149 - changes its state to Active. 8150 If the open Delay timer is not running, the local system: 8151 - resets the connect retry timer (sets to zero), and 8152 - Drops the TCP connection, 8153 - Releases all BGP resources, 8154 - and goes to Idle State. 8156 N.B. This is now event 18 (see issue 26). 8158 We are at consensus with this. 8160 This was discussed in the "Comments 21-30" thread: Comment #26. This 8161 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 8163 3.46 Handling of Event 17 in Active state 8165 Status: Consensus 8166 Change: No 8167 Summary: See issue 13.4, this issue closed in favor of that one. 8169 Discussion: 8171 This began with Siva saying: 8173 We should now move into Idle state. Can we add 8175 % - Goes to Idle state 8177 Sue replied that she thought this should be bundled in with the issue 8178 tracked in 13.4. Since no one objected, this issue has been closed 8179 in favor of that one. 8181 This was discussed in the "Comments 21-30" thread: Comment #27. 8183 3.47 Handling of Event 19 in Active state 8185 Status: Consensus 8186 Change: Yes 8187 Summary: Add the new text in the discussion section. 8189 Discussion: 8191 This began with Siva suggesting: 8193 > - Set the Hold timer to a large value (4 minutes), 8195 Since OPEN messages have been exchanged, can we change this to 8197 - If the negotiated Hold time is not 0, set the Hold time to 8198 - the negotiated value 8200 Sue replied that: 8202 The text in Active and Open Sent needs to be the same. 8203 The text in Open Sent is: 8204 - sets the Hold timer according to the negotiated value 8205 (see section 4.2), and 8207 Which text do you prefer? 8209 Sue replied that this text would be added to the next draft: 8211 New text 8213 - if the hold timer value is non-zero, 8214 - starts the keepalive timer to initial value, 8215 - resets the hold timer to the negotiated value, 8216 - else if the hold timer is zero 8217 - resets the keepalive timer (set to zero), 8218 - resets the hold timer to zero. 8220 This seems to address Siva's concerns, this issue is at consensus, if 8221 there are objections, we can reopen it. 8223 This was discussed in the "Comments 21-30" thread: Comment #28. This 8224 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 8226 3.48 Handling of Event 2 in Active state 8228 Status: Consensus 8229 Change: Yes 8230 Summary: Update the draft with the text at the end of the discussion 8231 section. 8233 Discussion: 8235 Siva opened with: 8237 > A manual stop event[Event2], the local system: 8238 > - Sends a notification with a Cease, 8239 > - drops the Transport connection 8241 These two actions are possible only if a transport connection had 8242 already been established. How about changing the text to 8244 % - If a transport connection had been successfully established 8245 % - Send a Notification with a Cease 8246 % - Drop the Transport Connection 8248 Sue counter suggested: 8250 A manual stop event [Event 2], the local system 8251 - Drop the TCP connection, 8252 - Release all BGP resources, 8253 - resets the connection retry timer [sets to zero], 8254 - goes to Idle. 8256 Jeff replied: 8258 I'm rather confused. Under exactly what circumstances can we be 8259 in the Active state and have an active TCP connection at all? 8260 Ditto for having any BGP resources? 8262 Going to Idle is fine. 8264 Tom offered this example: 8266 eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK 8267 received, Delay Open flag set and there we are. Most events are now 8268 possible either from a well-implemented remote peer or a badly 8269 implemented remote peer. 8271 Sue asked if there were any additional comments, if not, the text 8272 will be: 8274 A manual stop event[Event2], the local system: 8275 - Sends a NOTIFICATION with a Cease, 8276 - releases all BGP resources including 8277 - stopping the Open delay timer 8278 - drops the TCP connection, 8279 - sets ConnectRetryCnt (connect retry count) to zero 8280 - resets the connect retry timer (sets to zero), 8281 - changes its state to Idle. 8283 There have been no additional comments, we will use the text Sue 8284 proposed. 8286 This was discussed in the "Comments 21-30" thread: Comment #29. This 8287 was also brought up in the "BGP-19: Issue 34-35, 40-48" thread. 8289 3.49 Default Event handling in Active state 8291 Status: Consensus 8292 Change: No 8293 Summary: No routes in active. 8295 Discussion: 8297 Siva began with: 8299 To ensure consistency with E2 handling, can we add 8301 % - If any BGP Routes exist, delete the routes 8303 Sue replied: 8305 Comment: Yakov and Jeff noted, there are no routes in Active state. 8307 Since there were no responses disagreeing, we'll consider this closed 8308 unless someone wants to open it back up. 8310 This was discussed in the "Comments 21-30" thread: Comment #30. 8312 3.50 Clearing Hold timer in OpenSent, OpenConfirm and Established State 8314 Status: Consensus 8315 Change: No 8316 Summary: This issue is addressed in the "Clear BGP resources" 8318 Discussion: 8320 This began with Siva stating: 8322 In all event handling where we go to Idle state, we need to clear 8323 the Hold Timer as well. 8325 Sue replied that: 8327 issue resolve one way last Jan - March 8328 Clearing of keep alive timer included 8329 in Clear BGP resources 8331 No response to this yet, but since this seems to be resolved it is at 8332 consensus unless someone objects. 8334 This was discussed in the "Comments 30-36" thread: Comment #31. 8336 3.51 Clearing Keepalive timer in OpenConfirm and Established State 8338 Status: Consensus 8339 Change: No 8340 Summary: This issue is addressed in the "Clear BGP resources" 8342 Discussion: 8344 This began with Siva stating: 8346 In all event handling where we go to Idle state, we need to clear 8347 the Keepalive Timer as well. 8349 Sue replied that: 8351 issue resolve one way last Jan - March 8352 Clearing of keep alive timer included 8353 in Clear BGP resources 8355 No response to this yet, but since this seems to be resolved it is at 8356 consensus unless someone objects. 8358 This was discussed in the "Comments 30-36" thread: Comment #32. 8360 3.52 Handling Event 18 in the OpenSent state (Keepalive Timer) 8362 Status: Consensus 8363 Change: Yes 8364 Summary: Make the event optional. 8366 Discussion: 8368 This began with Siva asking: 8370 Why do we start the Keepalive timer at this stage ? Isn't it 8371 sufficient to do so when we move into Established state ? 8373 Sue replied: 8375 An earlier comment from Tom (and you) requested the following: 8377 <---Open 8378 [Open sent state] 8380 Open--> 8381 [Event 18] 8383 <---Open 8384 <---Keepalive 8385 [Action from Event 18 in Open Sent] 8386 [Open Confirm] 8387 Keepalive -> [Event 25] 8389 [established] 8391 What do implementations do? We'll have to query implementations. 8393 Jeff added: 8395 I'm assuming the second OPEN going from right to left is a typo. 8396 If it isn't, thats a FSM error to the peer on the left. 8398 Theoretically, an implementation that utilizes its keepalive timer 8399 to send the first keepalive to transition to Established is 8400 still interoperable. However: 8402 o Keepalives can be disabled by negotiating hold time of zero 8403 o We really shouldn't need to restart the Keepalive timer. 8404 If there is a delay in the keepalive that transitions from 8405 OpenConfirm to Established, its due to the transport connection. 8406 It should be reliable and it *should* get through. If it 8407 doesn't, there's other problems and the hold timer for the 8408 peer on the right should do the Right Thing and drop the 8409 connection. 8411 > What do implementations do? We'll have to query implementations. 8413 GateD at least waits to enter the Established state prior to 8414 starting the KeepAlive timer. 8416 Tom also added: 8418 My comment was that if we do not send a KeepAlive (and start the 8419 KeepAlive timer), on exiting from Active with Event 19 to 8420 OpenConfirm then we never will and the connection will die. Open 8421 Confirm state means valid Open received so we must send a KeepAlive 8422 to acknowledge the Open (as pointed out in Jeff's other posting) 8423 and we never do it in OpenConfirm state itself (unless the KeepAlive 8424 timer expires which it cannot because we have not started it). 8426 So for me, OpenSent state Event 18 was and is correct, sending the 8427 KeepAlive without which the connection goes no further and Active 8428 state Event 19 needs to be brought into line. 8430 To say that the timer is started when entering Established state is 8431 fine except for a slight problem; we have no way in this FSM of 8432 defining actions that are taken on entering a state, only actions to 8433 be taken on leaving another state so that is why the KeepAlive 8434 actions need to be where they are (or are not in the case of Active 8435 state Event 19). 8437 Sue replied, asking more implementors to chime in on what they do for 8438 this part of the FSM. 8440 Curtis replied that we should: 8442 Make it optional. Timing out in open or open-sent has never been 8443 much of an issue, so whether one or three keepalive get sent 8444 shouldn't be a hot topic. 8446 Sue said that this was fine, and she would work on text specifying 8447 optional. 8449 Jeff replied regarding GateD's behavior: 8451 GateD will start its keepalive timer while in this state, so 8452 multiple keepalives will be sent. 8454 As someone previously said, this is a "yawn" issue. But to choose 8455 one way or the other, we may potentially make someone in non- 8456 compliance. 8458 From the closure of issue 12, we have this text, which discusses 8459 Keepalives to consider in relation to the other keepalive issue here: 8461 Change 1: new text 8463 Active state - event 19 8465 If an Open is received with the Open Delay timer is 8466 running [Event 19], the local system 8467 - clears the connect retry timer (cleared to zero), 8468 - stops and clears the Open Delay timer 8469 - completes the BGP initialization, 8470 - stops and clears the Open Delay timer 8471 - sends an OPEN message, 8472 - send a Keepalive message, 8473 - if the hold timer value is non-zero, 8474 - starts the keepalive timer to initial value, 8475 - resets the hold timer to the negotiated value, 8476 else if the hold timer is zero 8477 - resets the keepalive timer (set to zero), 8478 - resets the hold timer to zero. 8480 - changes its state to OpenConfirm. 8482 If the value of the autonomous system field is the same as the 8483 local Autonomous System number, set the connection status to an 8484 internal connection; otherwise it is "external". 8486 Since there were no more comments, this is at consensus. 8488 This was discussed in the "Comments 30-36" thread: Comment #33. And 8489 in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State 8490 (Keepalive timer set)" thread. 8492 3.53 Established State MIB 8494 Status: Consensus 8495 Change: No 8496 Summary: MIB references pulled in favor of having them in the MIB 8497 document. 8498 See issue 8. 8500 Discussion: 8502 This began with Siva asking: 8504 Some event handling in the Established state do not set the MIB 8505 Reason when handling an event that causes an error. Can we add this 8506 ? 8508 Sue replied that we have pulled the MIB wording from the FSM. See 8509 issue 8. 8511 This was discussed in the "Comments 30-36" thread: Comment #34. 8513 3.54 State impact of not supporting Optional Events 8515 Status: Consensus 8516 Change: Yes 8517 Summary: Add the text at the end of the discussion section. 8519 Discussion: 8521 Siva stated that: 8523 For the events whose status is optional, can we state the impact of 8524 not supporting them (in terms of any interoperability issues). I 8525 understand that most of the optional events will not have such an 8526 impact; but a clarification statement for the optional events would 8527 benefit new implementors. 8529 Sue responded: 8531 Much of the support of optional parameters depends on policy. 8532 I could put a short note about the optional events and 8533 parameters as part of 8.1.5 or 8.2.1.3 8535 I think it fits better in 8.1.5. 8537 Optional: Events: 3-8, 12, 13-14[my suggestion] 8538 19, 22 8540 Timers: Idle Hold Timer 8541 Open Delay Timer 8543 Required flags for optional parameters: 8545 Open Delay Flag 8546 BGP Stop Flap 8548 Sue said she would try to work up more if it is agreed that this is 8549 on the right track. 8551 Sue provided this text to clarify the behavior associated with 8552 Optional Attributes: 8554 8.2.1.3 FSM and Optional Attributes 8556 Optional Attributes specify either flags that augment the normal 8557 processing of the BGP FSM, or optional timers. If a Optional 8558 attribute can be set on a system, the Events and the BGP FSM actions 8559 must be support. For example, if the following options can 8560 be set in a BGP implementation: AutoStart and Passive TCP connection 8561 Establishment flag, then the events 3, 4 and 5 must be supported. 8563 If an Optional attribute cannot be set (that is declared always off 8564 logically), the events supporting that set of options do not 8565 have to be supported. 8567 This was discussed in the "Comments 30-36" thread: Comment #35. 8569 3.55 New DelayOpen State 8571 Status: Consensus 8572 Change: No 8573 Summary: We've chosen not to reopen the debate about adding a 8574 DelayOpen State to the FSM. 8576 Discussion: 8578 Siva began with asking: 8580 Is delaying the sending of an OPEN message a standard industry 8581 practice ? 8583 Also, in the FSM, this has been handled by practically implementing 8584 a sub-state each, within the CONNECT and ACTIVE states. Won't the 8585 FSM look more simple if we just had a new DelayOpen state that we 8586 could move into ? 8588 Sue responded that this was something we have tried to do before, but 8589 that it spawned some degree of rabid response on both sides. Given 8590 our current mandate to stick with what is implemented, it is probably 8591 best not to reopen this debate. 8593 Unless someone badly wants to reopen this debate, the issue is at 8594 Consensus. 8596 This was discussed in the "Comments 21-30" thread: Comment #22. 8597 This was discussed in the "Comments 21-30" thread: Comment #26. 8598 This was discussed in the "Comments 30-36" thread: Comment #36. 8600 3.56 Clarify what is covered in the base document. 8602 Status: Consensus 8603 Change: Yes 8604 Summary: Add the text at the end of the discussion to clarify what is 8605 documented where with regard to BGP and its extensions. 8607 Discussion: 8609 This grew out of a discussion on how to use BGP Identifiers in an 8610 IPv6-only environment. In that discussion it became clear that the 8611 way the documents are currently structured it is not clear to new 8612 readers that extension specifications can and do specify behavior 8613 that supersedes the behavior specified in the base spec. To that end 8614 it was agreed that this text should be added: 8616 This document specifies the base behavior of the BGP protocol. 8617 This behavior can and is modified by extension specifications. 8618 When the protocol is extended the new behavior is fully documented 8619 in the extension specifications. 8621 This was discussed in the "Next-Hop in IPv6 only environments" 8622 thread. 8624 4. References 8626 [RFC1771] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", 8627 RFC 1771, March 1995. 8629 [BGP4Draft] Rekhter, Y., Lo, T., Hares, S., "A Border Gateway 8630 Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-20.txt. 8632 5. Author's Address: 8634 Andrew Lange 8635 Cable & Wireless 8636 1215 Borregas Ave. 8637 Sunnyvale, CA 94089 8638 andrewl@cw.net