draft-ietf-idr-bgp-issues-01.txt   draft-ietf-idr-bgp-issues-02.txt 
Internet Engineering Task Force A. Lange IDR A. Lange
INTERNET DRAFT Cable & Wireless Internet-Draft Alcatel-Lucent
June 2003 Intended status: Informational July 29, 2010
Expires December 2003 Expires: January 30, 2011
Issues in Revising BGP-4 Issues in Revising BGP-4
<draft-ietf-idr-bgp-issues-01.txt> draft-ietf-idr-bgp-issues-02
Abstract
This document records the issues discussed and the consensus reached
in the Interdomain Routing (IDR) Working Group during its efforts to
revise and bring up to date the base specification for the BGP-4
protocol.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This Internet-Draft is submitted in full conformance with the
all provisions of Section 10 of RFC2026. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 30, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
Abstract Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document records the issues discussed and the consensus reached This document is subject to BCP 78 and the IETF Trust's Legal
in the Interdomain Routing (IDR) Working Group during its efforts to Provisions Relating to IETF Documents
revise and bring up to date the base specification for the BGP-4 (http://trustee.ietf.org/license-info) in effect on the date of
protocol. publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
Status of this Memo......................................... 1
Abstract.................................................... 1
1. Introduction............................................. 5
2. The Issues from -17 to -18............................... 5
2.1 IDR WG Charter.......................................... 5
2.2 TCP Port................................................ 6
2.3 FSM wording for what state BGP accepts connections in... 7
2.4 BGP Identifier/Router ID................................ 7
2.5 Direct EBGP Peers....................................... 7
2.6 Disallow Private Addresses.............................. 8
2.7 Renumber Appendix Sections.............................. 8
2.8 Jitter Text............................................. 8
2.9 Reference to RFC904 - EGP Protocol...................... 13
2.10 Extending AS_PATH Attribute............................ 13
2.11 Rules for routes from Loc-RIB to Adj-RIB-Out -
Section 9.1............................................ 15
2.11.1 Rules for routes from Loc-RIB to Adj-RIB-Out -
Section 9.1.3........................................ 17
2.11.2 Rules for routes from Loc-RIB to Adj-RIB-Out -
Section 2............................................ 18
2.11.3 Documenting IBGP Multipath........................... 20
2.12 TCP Behavior Wording................................... 24
2.13 Next Hop for Originated Route.......................... 24
2.14 NEXT_HOP to Internal Peer.............................. 25
2.15 Grammer Fix............................................ 25
2.16 Need ToC, Glossary and Index........................... 26
2.17 Add References to other RFC-status BGP docs to base
spec................................................... 26
2.18 IP Layer Fragmentation................................. 26
2.19 Appendix Section 6.2: Processing Messages on a Stream
Protocol............................................... 27
2.20 Wording fix in Section 4.3............................. 28
2.21 Authentication Text Update............................. 28
2.22 Scope of Path Attribute Field.......................... 29
2.23 Withdrawn and Updated routes in the same UPDATE message 29
2.24 Addition or Deletion of Path Attributes................ 31
2.25 NEXT_HOP Semantics..................................... 32
2.26 Attributes with Multiple Prefixes...................... 32
2.27 Allow All Non-Destructive Messages to Refresh Hold
Timer.................................................. 33
2.28 BGP Identifier as Variable Quantity.................... 34
2.29 State Why Unresolveable Routes Should Be Kept in
Adj-RIB-In............................................. 34
2.30 Mention Other Message Types............................ 35
2.31 Add References to Additional Options................... 36
2.32 Clarify EGP Reference.................................. 36
2.32.1 EGP ORIGIN Clarification............................. 37
2.32.2 BGP Destination-based Forwarding Paradigm............ 41
2.33 Add "Optional Non-Transitive" to the MED Section....... 45
2.34 Timer & Counter Definition............................. 45
2.35 Fix Typo............................................... 46
2.36 Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 46
2.37 Combine "Unfeasible Routes" and "Withdrawn Routes"..... 46
2.38 Clarify Outbound Route Text............................ 48
2.39 Redundant Sentence Fragments........................... 49
2.40 Section 9.2.1.1 - Per Peer vs. Per Router
MinRouteAdvertisementInterval.......................... 50
2.41 Mention FSM Internal Timers............................ 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2.42 Delete the FSM Section................................. 51 2. The Issues from -17 to -18 . . . . . . . . . . . . . . . . . 6
2.43 Clarify the NOTIFICATION Section....................... 51 2.1. IDR WG Charter . . . . . . . . . . . . . . . . . . . . . 6
2.44 Section 6.2: OPEN message error handling............... 52 2.2. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . 7
2.45 Consistent References to BGP Peers/Connections/Sessions 54 2.3. FSM wording for what state BGP accepts connections in . . 8
2.46 FSM Connection Collision Detection..................... 55 2.4. BGP Identifier/Router ID . . . . . . . . . . . . . . . . 8
2.47 FSM - Add Explicit State Change Wording................ 57 2.5. Direct EBGP Peers . . . . . . . . . . . . . . . . . . . . 8
2.48 Explicitly Define Processing of Incoming Connections... 57 2.6. Disallow Private Addresses . . . . . . . . . . . . . . . 9
2.49 Explicitly Define Event Generation..................... 61 2.7. Renumber Appendix Sections . . . . . . . . . . . . . . . 9
2.50 FSM Timers............................................. 62 2.8. Jitter Text . . . . . . . . . . . . . . . . . . . . . . . 9
2.51 FSM ConnectRetryCnt.................................... 62 2.9. Reference to RFC904 - EGP Protocol . . . . . . . . . . . 14
2.52 Section 3: Keeping routes in Adj-RIB-In................ 63 2.10. Extending AS_PATH Attribute . . . . . . . . . . . . . . . 14
2.53 Section 4.3 - Routes v. Destinations - Advertise....... 64 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section
2.54 Section 4.3 - Routes v. Destinations - Withdraw........ 65 9.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.55 Section 4.3 - Description of AS_PATH length............ 67 2.11.1. Rules for routes from Loc-RIB to Adj-RIB-Out -
2.56 Section 6 - BGP Error Handling......................... 68 Section 9.1.3 . . . . . . . . . . . . . . . . . . . 18
2.57 Section 6.2 - Hold timer as Zero....................... 70 2.11.2. Rules for routes from Loc-RIB to Adj-RIB-Out -
2.58 Deprecation of ATOMIC_AGGREGATE........................ 71 Section 2 . . . . . . . . . . . . . . . . . . . . . 19
2.59 Section 4.3 - Move text................................ 79 2.11.3. Documenting IBGP Multipath . . . . . . . . . . . . . 21
2.60 Section 4.3 - Path Attributes.......................... 80 2.12. TCP Behavior Wording . . . . . . . . . . . . . . . . . . 25
2.61 Next Hop for Redistributed Routes...................... 81 2.13. Next Hop for Originated Route . . . . . . . . . . . . . . 25
2.62 Deprecate BGP Authentication Optional Parameter from 2.14. NEXT_HOP to Internal Peer . . . . . . . . . . . . . . . . 26
RFC1771................................................ 83 2.15. Grammar Fix . . . . . . . . . . . . . . . . . . . . . . . 26
2.63 Clarify MED Removal Text............................... 87 2.16. Need ToC, Glossary and Index . . . . . . . . . . . . . . 27
2.64 MED for Originated Routes.............................. 93 2.17. Add References to other RFC-status BGP docs to base
2.65 Rules for Aggregating with MED and NEXT_HOP............ 93 spec . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.66 Complex AS Path Aggregating............................ 94 2.18. IP Layer Fragmentation . . . . . . . . . . . . . . . . . 27
2.67 Counting AS_SET/AS_CONFED_*............................ 96 2.19. Appendix Section 6.2: Processing Messages on a Stream
2.68 Outbound Loop Detection................................ 97 Protocol . . . . . . . . . . . . . . . . . . . . . . . . 28
2.69 Appendix A - Other Documents........................... 99 2.20. Wording fix in Section 4.3 . . . . . . . . . . . . . . . 29
3. The Issues from -18 to -19............................... 99 2.21. Authentication Text Update . . . . . . . . . . . . . . . 29
3.1 Reference to RFC 1772................................... 99 2.22. Scope of Path Attribute Field . . . . . . . . . . . . . . 30
3.2 MUST/SHOULD Capitalization.............................. 99 2.23. Withdrawn and Updated routes in the same UPDATE message . 31
3.3 Fix Update Error Subcode 7 -- accidently removed........ 100 2.24. Addition or Deletion of Path Attributes . . . . . . . . . 32
3.4 Section 5.1.4 - Editorial Comment....................... 101 2.25. NEXT_HOP Semantics . . . . . . . . . . . . . . . . . . . 33
3.5 Section 9.1 - Change "all peers" to "peers"............. 101 2.26. Attributes with Multiple Prefixes . . . . . . . . . . . . 34
3.6 AS Loop Detection & Implicit Withdraws.................. 101 2.27. Allow All Non-Destructive Messages to Refresh Hold
3.7 Standardize FSM Timer Descriptions...................... 102 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8 FSM MIB enumerations.................................... 103 2.28. BGP Identifier as Variable Quantity . . . . . . . . . . . 35
3.9 Make "delete routes" language consistent................ 104 2.29. State Why Unresolveable Routes Should Be Kept in
3.10 Correct OpenSent and OpenConfirm delete wording........ 104 Adj-RIB-In . . . . . . . . . . . . . . . . . . . . . . . 35
3.11 Incorrect next state when the delay open timer expires. 105 2.30. Mention Other Message Types . . . . . . . . . . . . . . . 36
3.12 Entering OpenConfirm / Adding "Stop OpenDelay" action.. 105 2.31. Add References to Additional Options . . . . . . . . . . 37
3.13 FSM Missing Next States................................ 111 2.32. Clarify EGP Reference . . . . . . . . . . . . . . . . . . 37
3.13.1 FSM Missing Next States - Event 15 or 16 2.32.1. EGP ORIGIN Clarification . . . . . . . . . . . . . . 38
(Connect State)...................................... 111 2.32.2. BGP Destination-based Forwarding Paradigm . . . . . 42
3.13.2 FSM Missing Next States - Event 14 (Connect State)... 113
3.13.3 FSM Missing Next States - Event 15 or 16
(Active State)....................................... 115
3.13.4 FSM Missing Next States - Event 13-17
(TCP Connection)..................................... 116
3.13.5 FSM Missing Next States - Event 17 (Connect State)... 118
3.13.6 FSM Missing Next States - Event 18 (Open Confirm).... 121
3.14 FSM - Peer Oscillation Damping......................... 124
3.15 FSM - Consistent FSM Event Names....................... 124
3.16 Many Editorial Comments................................ 127
3.17 Section 3, Page 8, Paragraph 3 - Obsolete?............. 132
3.18 MED Removal Text....................................... 135
3.19 Security Considerations................................ 138
3.20 Peer Oscillation Damping............................... 138
3.21 Session Attributes - IdleHold Timer.................... 139
3.22 Specify New Attributes (Accept Connections/Peer
Oscillation Damping)................................... 141
3.23 Event1/Event2 Clean Up................................. 142
3.24 Events 3, 5, 6 & 7 Give Examples....................... 142
3.25 Event 4 & 5 Session Initiation Text.................... 144
3.26 Event 4 & 5 - bgp_stop_flap option..................... 145
3.27 Event 5 Clarification.................................. 147
3.28 Timer Events Definition - Make Consistent.............. 148
3.29 Event 8 - Clean Up..................................... 148
3.30 Hold Timer - Split?.................................... 149
3.31 OpenDelay Timer Definition............................. 149
3.32 Definition of TCP Connection Accept (Event 13)......... 149
3.33 Event 13 & 14 - Valid Addresses & Ports................ 150
3.34 Event 17 - TCP Connection Fails to TCP Connection
Termination............................................ 151
3.35 Making Definition Style Consistent..................... 151
3.36 Event 19 - Definition Cleanup.......................... 154
3.37 Event 22 - Cleanup..................................... 155
3.38 FSM Description - ConnectRetry Count................... 156
3.39 Handling Event 7 (Auto Stop to Idle State processing).. 157
3.40 Clearing the Connection Retry Timer.................... 157
3.41 Handling of Event 14 in the Connect State.............. 159
3.42 Handling events 20, 21 in the Connect State and Active
State.................................................. 160
3.43 Handling the default events in the Connect state....... 163
3.44 Handling Event 23 in Connect and OpenSent.............. 165
3.45 Event 17 in the Connect state.......................... 167
3.46 Handling of Event 17 in Active state................... 170
3.47 Handling of Event 19 in Active state................... 170
3.48 Handling of Event 2 in Active state.................... 171
3.49 Default Event handling in Active state................. 173
3.50 Clearing Hold timer in OpenSent, OpenConfirm and
Established State...................................... 173
3.51 Clearing Keepalive timer in OpenConfirm and Established
State.................................................. 174
3.52 Handling Event 18 in the OpenSent state (Keepalive
Timer)................................................. 174
3.53 Established State MIB.................................. 177
3.54 State impact of not supporting Optional Events......... 177
3.55 New DelayOpen State.................................... 178
3.56 Clarify what is covered in the base document........... 178
4. References............................................... 179
5. Author's Address......................................... 180
Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2.33. Add "Optional Non-Transitive" to the MED Section . . . . 46
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 2.34. Timer & Counter Definition . . . . . . . . . . . . . . . 46
document are to be interpreted as described in RFC 2119 [RFC2119]. 2.35. Fix Typo . . . . . . . . . . . . . . . . . . . . . . . . 47
2.36. Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary . 47
2.37. Combine "Unfeasible Routes" and "Withdrawn Routes" . . . 47
2.38. Clarify Outbound Route Text . . . . . . . . . . . . . . . 49
2.39. Redundant Sentence Fragments . . . . . . . . . . . . . . 50
2.40. Section 9.2.1.1 - Per Peer vs. Per Router
MinRouteAdvertisementInterval . . . . . . . . . . . . . . 51
2.41. Mention FSM Internal Timers . . . . . . . . . . . . . . . 51
2.42. Delete the FSM Section . . . . . . . . . . . . . . . . . 52
2.43. Clarify the NOTIFICATION Section . . . . . . . . . . . . 52
2.44. Section 6.2: OPEN message error handling . . . . . . . . 53
2.45. Consistent References to BGP Peers/Connections/Sessions . 55
2.46. FSM Connection Collision Detection . . . . . . . . . . . 56
2.47. FSM - Add Explicit State Change Wording . . . . . . . . . 58
2.48. Explicitly Define Processing of Incoming Connections . . 58
2.49. Explicitly Define Event Generation . . . . . . . . . . . 62
2.50. FSM Timers . . . . . . . . . . . . . . . . . . . . . . . 63
2.51. FSM ConnectRetryCnt . . . . . . . . . . . . . . . . . . . 63
2.52. Section 3: Keeping routes in Adj-RIB-In . . . . . . . . . 64
2.53. Section 4.3 - Routes v. Destinations - Advertise . . . . 65
2.54. Section 4.3 - Routes v. Destinations - Withdraw . . . . . 66
2.55. Section 4.3 - Description of AS_PATH length . . . . . . . 68
2.56. Section 6 - BGP Error Handling . . . . . . . . . . . . . 69
2.57. Section 6.2 - Hold timer as Zero . . . . . . . . . . . . 71
2.58. Deprecation of ATOMIC_AGGREGATE . . . . . . . . . . . . . 72
2.59. Section 4.3 - Move text . . . . . . . . . . . . . . . . . 80
2.60. Section 4.3 - Path Attributes . . . . . . . . . . . . . . 81
2.61. Next Hop for Redistributed Routes . . . . . . . . . . . . 82
2.62. Deprecate BGP Authentication Optional Parameter from
RFC1771 . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.63. Clarify MED Removal Text . . . . . . . . . . . . . . . . 88
2.64. MED for Originated Routes . . . . . . . . . . . . . . . . 93
2.65. Rules for Aggregating with MED and NEXT_HOP . . . . . . . 94
2.66. Complex AS Path Aggregating . . . . . . . . . . . . . . . 95
2.67. Counting AS_SET/AS_CONFED_* . . . . . . . . . . . . . . . 97
2.68. Outbound Loop Detection . . . . . . . . . . . . . . . . . 98
2.69. Appendix A - Other Documents . . . . . . . . . . . . . . 99
3. The Issues from -18 to -19 . . . . . . . . . . . . . . . . . 100
3.1. Reference to RFC 1772 . . . . . . . . . . . . . . . . . . 100
3.2. MUST/SHOULD Capitalization . . . . . . . . . . . . . . . 100
3.3. Fix Update Error Subcode 7 -- accidently removed . . . . 101
3.4. Section 5.1.4 - Editorial Comment . . . . . . . . . . . . 101
3.5. Section 9.1 - Change "all peers" to "peers" . . . . . . . 102
3.6. AS Loop Detection & Implicit Withdraws . . . . . . . . . 102
3.7. Standardize FSM Timer Descriptions . . . . . . . . . . . 103
3.8. FSM MIB enumerations . . . . . . . . . . . . . . . . . . 104
3.9. Make "delete routes" language consistent . . . . . . . . 104
3.10. Correct OpenSent and OpenConfirm delete wording . . . . . 105
3.11. Incorrect next state when the delay open timer expires . 105
3.12. Entering OpenConfirm / Adding "Stop OpenDelay" action . . 106
3.13. FSM Missing Next States . . . . . . . . . . . . . . . . . 110
3.13.1. FSM Missing Next States - Event 15 or 16 (Connect
State) . . . . . . . . . . . . . . . . . . . . . . . 111
3.13.2. FSM Missing Next States - Event 14 (Connect State) . 112
3.13.3. FSM Missing Next States - Event 15 or 16 (Active
State) . . . . . . . . . . . . . . . . . . . . . . . 114
3.13.4. FSM Missing Next States - Event 13-17 (TCP
Connection) . . . . . . . . . . . . . . . . . . . . 114
3.13.5. FSM Missing Next States - Event 17 (Connect State) . 116
3.13.6. FSM Missing Next States - Event 18 (Open Confirm) . 118
3.14. FSM - Peer Oscillation Damping . . . . . . . . . . . . . 120
3.15. FSM - Consistent FSM Event Names . . . . . . . . . . . . 121
3.16. Many Editorial Comments . . . . . . . . . . . . . . . . . 123
3.17. Section 3, Page 8, Paragraph 3 - Obsolete? . . . . . . . 127
3.18. MED Removal Text . . . . . . . . . . . . . . . . . . . . 130
3.19. Security Considerations . . . . . . . . . . . . . . . . . 133
3.20. Peer Oscillation Damping . . . . . . . . . . . . . . . . 133
3.21. Session Attributes - IdleHold Timer . . . . . . . . . . . 134
3.22. Specify New Attributes (Accept Connections/Peer
Oscillation Damping) . . . . . . . . . . . . . . . . . . 135
3.23. Event1/Event2 Clean Up . . . . . . . . . . . . . . . . . 136
3.24. Events 3, 5, 6 & 7 Give Examples . . . . . . . . . . . . 137
3.25. Event 4 & 5 Session Initiation Text . . . . . . . . . . . 138
3.26. Event 4 & 5 - bgp_stop_flap option . . . . . . . . . . . 139
3.27. Event 5 Clarification . . . . . . . . . . . . . . . . . . 141
3.28. Timer Events Definition - Make Consistent . . . . . . . . 141
3.29. Event 8 - Clean Up . . . . . . . . . . . . . . . . . . . 142
3.30. Hold Timer - Split? . . . . . . . . . . . . . . . . . . . 142
3.31. OpenDelay Timer Definition . . . . . . . . . . . . . . . 143
3.32. Definition of TCP Connection Accept (Event 13) . . . . . 143
3.33. Event 13 & 14 - Valid Addresses & Ports . . . . . . . . . 144
3.34. Event 17 - TCP Connection Fails to TCP Connection
Termination . . . . . . . . . . . . . . . . . . . . . . . 144
3.35. Making Definition Style Consistent . . . . . . . . . . . 145
3.36. Event 19 - Definition Cleanup . . . . . . . . . . . . . . 147
3.37. Event 22 - Cleanup . . . . . . . . . . . . . . . . . . . 148
3.38. FSM Description - ConnectRetry Count . . . . . . . . . . 149
3.39. Handling Event 7 (Auto Stop) to Idle State processing . . 149
3.40. Clearing the Connection Retry Timer . . . . . . . . . . . 150
3.41. Handling of Event 14 in the Connect State . . . . . . . . 151
3.42. Handling events 20, 21 in the Connect State and Active
State . . . . . . . . . . . . . . . . . . . . . . . . . . 152
3.43. Handling the default events in the Connect state . . . . 155
3.44. Handling Event 23 in Connect and OpenSent . . . . . . . . 156
3.45. Event 17 in the Connect state . . . . . . . . . . . . . . 158
3.46. Handling of Event 17 in Active state . . . . . . . . . . 161
3.47. Handling of Event 19 in Active state . . . . . . . . . . 161
3.48. Handling of Event 2 in Active state . . . . . . . . . . . 162
3.49. Default Event handling in Active state . . . . . . . . . 163
3.50. Clearing Hold timer in OpenSent, OpenConfirm and
Established State . . . . . . . . . . . . . . . . . . . . 164
3.51. Clearing Keepalive timer in OpenConfirm and
Established State . . . . . . . . . . . . . . . . . . . . 164
3.52. Handling Event 18 in the OpenSent state (Keepalive
Timer) . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.53. Established State MIB . . . . . . . . . . . . . . . . . . 167
3.54. State impact of not supporting Optional Events . . . . . 168
3.55. New DelayOpen State . . . . . . . . . . . . . . . . . . . 169
3.56. Clarify what is covered in the base document . . . . . . 169
4. Security Considerations . . . . . . . . . . . . . . . . . . . 170
5. Normative References . . . . . . . . . . . . . . . . . . . . 170
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 170
1. Introduction 1. Introduction
This document records the issues discussed and the consensus reached This document records the issues discussed and the consensus reached
in the Interdomain Routing (IDR) Working Group during its efforts to in the Interdomain Routing (IDR) Working Group during its efforts to
revise and bring up to date the base specification for the BGP-4 revise and bring up to date the base specification for the BGP-4
protocol. The rational for doing this is simple: Experience has protocol. The rational for doing this is simple: Experience has
demonstrated that the same issues and questions tend to come up again demonstrated that the same issues and questions tend to come up again
and again. This memo will document not only the decisions on these and again. This memo will document not only the decisions on these
issues but also how and why the working group reached those issues but also how and why the working group reached those
conclusions. We hope that this will help make future discussions conclusions. We hope that this will help make future discussions
more fruitful by providing them with a historical context. more fruitful by providing them with a historical context.
This document traces the evolution of the BGP-4 base specification This document traces the evolution of the BGP-4 base specification
from its incarnation as draft-ietf-idr-bgp4-17.txt through the big from its incarnation as draft-ietf-idr-bgp4-17.txt through the big
revision and update push culminating in draft-ietf-idr-bgp4-19.txt. revision and update push culminating in draft-ietf-idr-bgp4-19.txt.
It is divided into two main sections. The first deals with the It is divided into two main sections. The first deals with the
issues discussed between -17 and -18, and the second deals with the issues discussed between -17 and -18, and the second deals with the
issues discussed between -18 and -19. issues discussed between -18 and -19.
N.B. There is no rhyme or reason to the numbering scheme other than N.B. There is no rhyme or reason to the numbering scheme other than
unique tags to address the issues. unique tags to address the issues.
2. The Issues from -17 to -18. 2. The Issues from -17 to -18
This section lists the issues discussed on the list from late August This section lists the issues discussed on the list from late August
to late October 2002. to late October 2002.
2.1 IDR WG Charter 2.1. IDR WG Charter
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: New charter adopted. Summary: New charter adopted.
Discussion: Discussion:
A variety of discussions surrounded the new charter. The rough A variety of discussions surrounded the new charter. The rough
consensus is to accept the new charter that the AD's have proposed, consensus is to accept the new charter that the AD's have proposed,
and to push as hard a possible to get the base spec to RFC status so and to push as hard a possible to get the base spec to RFC status so
other drafts that are dependent can also move forward. other drafts that are dependent can also move forward.
For our information, Alex has provided these approximate time lines: For our information, Alex has provided these approximate time lines:
Stage Anticipated delay Comment Stage Anticipated delay Comment
-------------------------------------------------------------------- --------------------------------------------------------------------
AD-review 1-4 weeks The document may go back AD-review 1-4 weeks The document may go back depending on to the WG
depending on to the WG for the for the workload AD-review comments to be addressed; this would
workload AD-review comments to be introduce additional delay.
addressed; this would
introduce additional
delay.
IETF LC 2 weeks Same as above IETF LC 2 weeks Same as above
IESG review & 1-2 weeks depending Same as above IESG review & 1-2 weeks depending Same as above telechat on when the
telechat on when the IETF LC ends IETF LC ends
-------------------------------------------------------------------- --------------------------------------------------------------------
Note that if the document is sent back to the WG at some stage, Note that if the document is sent back to the WG at some stage,
required changes may warrant an additional WG Last Call. required changes may warrant an additional WG Last Call.
I can personally commit to a 2-week upper bound for the AD-review I can personally commit to a 2-week upper bound for the AD-review
period. Bill may have a different timer granularity. period. Bill may have a different timer granularity.
The opinions expressed on this were 7 in favor, 4 against. The opinions expressed on this were 7 in favor, 4 against.
This thread has messages subjects of "BGP spec and IDR WG charter" This thread has messages subjects of "BGP spec and IDR WG charter"
and "IDR WG charter". and "IDR WG charter".
2.2 TCP Port 2.2. TCP Port
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Summary:
Change: "BGP uses TCP port 179 for establishing its connections."
To: "BGP listens on TCP port 179." Change:
"BGP uses TCP port 179 for establishing its connections."
To:
"BGP listens on TCP port 179."
Discussion: Discussion:
There has been a discussion on clarifying the wording in Section 2, There has been a discussion on clarifying the wording in Section 2,
on which port BGP uses. The original text was: on which port BGP uses. The original text was:
"BGP uses TCP port 179 for establishing its connections." "BGP uses TCP port 179 for establishing its connections."
The proposed new text is: The proposed new text is:
"BGP listens on TCP port 179." "BGP listens on TCP port 179."
There seems to be a rough consensus that the new text is better. There seems to be a rough consensus that the new text is better.
This thread has a message subject of "Review: Section 2, TCP Port This thread has a message subject of "Review: Section 2, TCP Port
179" 179"
2.3 FSM wording for what state BGP accepts connections in 2.3. FSM wording for what state BGP accepts connections in
Status: Consensus Status: Consensus
Change: No Change: No
Summary: No change necessary Summary: No change necessary
Discussion: Discussion:
An issue was brought up later in the "Review: Section 2, TCP Port An issue was brought up later in the "Review: Section 2, TCP Port
179" thread about the words in the FSM for what state BGP accepts 179" thread about the words in the FSM for what state BGP accepts
connections in. The consensus is that the existing wording is clear. connections in. The consensus is that the existing wording is clear.
2.4 BGP Identifier/Router ID 2.4. BGP Identifier/Router ID
Status: Consensus Status: Consensus
Change: No Change: No
Summary: No change necessary to base draft. Perhaps in a BCP. Summary: No change necessary to base draft. Perhaps in a BCP.
Discussion: Discussion:
The "admin dist/gp spec proposal", "Router ID" and "bgp spec The "admin dist/gp spec proposal", "Router ID" and "bgp spec
proposal" threads discussed the BGP Identifier and how close or not proposal" threads discussed the BGP Identifier and how close or not
it is to IGP's Router ID. The consensus was that this discussion is it is to IGP's Router ID. The consensus was that this discussion is
better saved for a BCP draft, and that it does not need to be better saved for a BCP draft, and that it does not need to be
contained in the base spec. contained in the base spec.
2.5 Direct EBGP Peers 2.5. Direct EBGP Peers
Status: Consensus Status: Consensus Change: No Summary: A recollection that ebgp peers
Change: No must be direct. No text proposed, no discussion.
Summary: A recollection that ebgp peers must be direct. No text
proposed, no discussion.
Discussion: Discussion:
Jonathan recalled something that stated that ebgp peers must be Jonathan recalled something that stated that ebgp peers must be
direct. No specific sections were quoted. direct. No specific sections were quoted.
Yakov responded to this with: Yakov responded to this with:
Section 5.1.3 talks about both the case where ebgp peers are 1 IP hop Section 5.1.3 talks about both the case where ebgp peers are 1 IP hop
away from each other: away from each other:
skipping to change at page 8, line 23 skipping to change at page 9, line 10
as well as the case where they are multiple IP hops away from each as well as the case where they are multiple IP hops away from each
other: other:
3) When sending a message to an external peer X, and the peer is 3) When sending a message to an external peer X, and the peer is
multiple IP hops away from the speaker (aka "multi hop EBGP"): multiple IP hops away from the speaker (aka "multi hop EBGP"):
And emphasized that multi hop EBGP does exist. And emphasized that multi hop EBGP does exist.
This came up in the "bgp draft review" thread. This came up in the "bgp draft review" thread.
2.6 Disallow Private Addresses 2.6. Disallow Private Addresses
Status: Consensus Status: Consensus
Change: No Change: No
Summary: No change necessary Summary: No change necessary
Discussion: Discussion:
In the tread entitled "bgp draft review": In the thread entitled "bgp draft review":
Mentioned explicitly disallowing private addresses. The consensus Mentioned explicitly disallowing private addresses. The consensus
was that there is no reason to disallow them. Which IP addresses was that there is no reason to disallow them. Which IP addresses
peers use is an operational issue. peers use is an operational issue.
2.7 Renumber Appendix Sections 2.7. Renumber Appendix Sections
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Rename/renumber appendix sections so they do not have the Summary: Rename/renumber appendix sections so they do not have the
same numbers as sections of the main text. same numbers as sections of the main text.
Discussion: Discussion:
In the tread entitled "bgp draft review": In the tread entitled "bgp draft review":
This thread brought up renaming sections in the appendix to avoid This thread brought up renaming sections in the appendix to avoid
confusion with sections of the same number in the main text. confusion with sections of the same number in the main text.
Yakov responded that he would do so in the next edition. Yakov responded that he would do so in the next edition.
2.8 Jitter Text 2.8. Jitter Text
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Summary:
Get rid of section 9.2.1.3 ("Jitter"). Move the text to an
Appendix: "BGP Timers" Expand text to indicate that jitter applies
to all timers, including ConnectRetry.
The text for the appendix is listed at the end of the discussion. Get rid of section 9.2.1.3 ("Jitter"). Move the text to an
Appendix: "BGP Timers" Expand text to indicate that jitter applies
to all timers, including ConnectRetry.
The text for the appendix is listed at the end of the discussion.
Discussion: Discussion:
In the tread entitled "bgp draft review": The thread also proposed: In the tread entitled "bgp draft review": The thread also proposed:
"jitter should be applied to the timers associated with "jitter should be applied to the timers associated with
MinASOriginationInterval, Keepalive, and MinASOriginationInterval, Keepalive, and
MinRouteAdvertisementInterval" MinRouteAdvertisementInterval"
Be changed to: Be changed to:
skipping to change at page 9, line 38 skipping to change at page 10, line 27
Yakov agreed with making some changes and suggested that we make sure Yakov agreed with making some changes and suggested that we make sure
that jitter is applied to all timers. Specifically, he proposes we that jitter is applied to all timers. Specifically, he proposes we
get rid of section 9.2.1.3 ("Jitter"), move the text of this section get rid of section 9.2.1.3 ("Jitter"), move the text of this section
into Appendix "BGP Timers", and expand the text to indicate that into Appendix "BGP Timers", and expand the text to indicate that
jitter applies to ConnectRetry timer as well. jitter applies to ConnectRetry timer as well.
Jonathan, the original commenter, agreed with Yakov's suggestion. Jonathan, the original commenter, agreed with Yakov's suggestion.
In a follow-up to this issue, there was a question raised about the In a follow-up to this issue, there was a question raised about the
values we have specified for timers in the document. Specifically: values we have specified for timers in the document. Specifically:
The ConnectRetry timer is should have a value that is 'sufficiently The ConnectRetry timer is should have a value that is 'sufficiently
large to allow TCP initialization. Application of jitter can reduce large to allow TCP initialization. Application of jitter can reduce
the this value (by up to 25%). A configuration which the ConnectRetry the this value (by up to 25%). A configuration which the
timer has been pegged at a value close to TCP connection time may ConnectRetry timer has been pegged at a value close to TCP connection
cause a connection to be terminated as a result of this jitter. Is time may cause a connection to be terminated as a result of this
this a cause for concern ? jitter. Is this a cause for concern ?
The default value suggested for ConnectRetry (120 seconds) is The default value suggested for ConnectRetry (120 seconds) is
sufficiently large that event with a jitter of 0.75, it will be sufficiently large that event with a jitter of 0.75, it will be
greater than TCP's connection establishment timer. greater than TCP's connection establishment timer.
Is adding a jitter to the ConnectRetry timer a standard practice ? Is adding a jitter to the ConnectRetry timer a standard practice ?
What benefit does this provide ? What benefit does this provide ?
Curtis responded to this with: Curtis responded to this with:
The TCP connection establishment timer is 75 seconds (sysctl yield The TCP connection establishment timer is 75 seconds (sysctl yield
"net.inet.tcp.keepinit: 75000" in BSD-oids). "net.inet.tcp.keepinit: 75000" in BSD-oids).
The ConnectRetry determines when to make a second attempt after a The ConnectRetry determines when to make a second attempt after a
prior attempt to connect has failed. It is to avoid a rapid prior attempt to connect has failed. It is to avoid a rapid
succession of retries on immediate failures (for example "Connection succession of retries on immediate failures (for example "Connection
refused" if the peer was in the middle of a reboot, Network refused" if the peer was in the middle of a reboot, Network
Unreachable if you can't get there from here, etc) but also covers Unreachable if you can't get there from here, etc) but also covers
skipping to change at page 10, line 24 skipping to change at page 11, line 14
the case where the TCP SYN goes off and is never heard from again. the case where the TCP SYN goes off and is never heard from again.
And Jonathan replied with this information about current practice: And Jonathan replied with this information about current practice:
It seems to me that if you bring up all bgp peers at once it may lead It seems to me that if you bring up all bgp peers at once it may lead
to load spikes on the network. Cisco seems to wait 27.5 +/- 2.5 to load spikes on the network. Cisco seems to wait 27.5 +/- 2.5
seconds for IBGP, and 40 +/- 5 seconds for EBGP--20 sec. from config seconds for IBGP, and 40 +/- 5 seconds for EBGP--20 sec. from config
time to the "open active, delay" jittered delay assignment plus the time to the "open active, delay" jittered delay assignment plus the
jittered delay (5 to 10 sec. for IBGP, and 15 to 25 sec. for EBGP). jittered delay (5 to 10 sec. for IBGP, and 15 to 25 sec. for EBGP).
This would also apply for "no neighbor x.x.x.x shutdown". Their This would also apply for "no neighbor x.x.x.x shutdown". Their
value of ConnectRetry is 60sec. though, not sure how this value is value of ConnectRetry is 60sec. though, not sure how this value is
used (based on above). Maybe some Cisco folks can chime in on this used (based on above). Maybe some Cisco folks can chime in on this
one??? one???
I did not check Juniper. I did not check Juniper.
Also, interestingly, they do not apply jitter to the other timers (as Also, interestingly, they do not apply jitter to the other timers (as
far as I can tell), but I don't see a problem with this. far as I can tell), but I don't see a problem with this.
Another timer that they use that is not mentioned in the draft/rfc is Another timer that they use that is not mentioned in the draft/rfc is
the next hop resolution timer which is 30 seconds. Although it would the next hop resolution timer which is 30 seconds. Although it would
skipping to change at page 11, line 29 skipping to change at page 12, line 18
The suggested value for the MinRouteAdvertisementInterval is 30 The suggested value for the MinRouteAdvertisementInterval is 30
seconds. seconds.
An implementation of BGP MUST allow the Hold Time timer to be An implementation of BGP MUST allow the Hold Time timer to be
configurable, and MAY allow the other timers to be configurable. configurable, and MAY allow the other timers to be configurable.
To minimize the likelihood that the distribution of BGP messages by a To minimize the likelihood that the distribution of BGP messages by a
given BGP speaker will contain peaks, jitter should be applied to the given BGP speaker will contain peaks, jitter should be applied to the
timers associated with MinASOriginationInterval, Keepalive, timers associated with MinASOriginationInterval, Keepalive,
MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker
shall apply the same jitter to each of these quantities regardless of shall apply the same jitter to each of these quantities regardless of
the destinations to which the updates are being sent; that is, jitter the destinations to which the updates are being sent; that is, jitter
will not be applied on a "per peer" basis. will not be applied on a "per peer" basis.
The amount of jitter to be introduced shall be determined by The amount of jitter to be introduced shall be determined by
multiplying the base value of the appropriate timer by a random multiplying the base value of the appropriate timer by a random
factor which is uniformly distributed in the range from 0.75 to 1.0. factor which is uniformly distributed in the range from 0.75 to 1.0.
Jeff & Ben agreed with this. Jeff & Ben agreed with this.
Justin suggested that we move the range from 0.75 to 1.25 to ensure Justin suggested that we move the range from 0.75 to 1.25 to ensure
that the average is around the configured value. Yakov agreed with that the average is around the configured value. Yakov agreed with
Justin's changes. Jonathan disagreed, arguing that it was out-of- Justin's changes. Jonathan disagreed, arguing that it was out-of-
scope for the task of clarifying the text only. Justin agreed and scope for the task of clarifying the text only. Justin agreed and
withdrew his comment. withdrew his comment.
Curtis liked the general text, but suggested these modifications: Curtis liked the general text, but suggested these modifications:
minor improvement (not really an objection) -- s/suggested minor improvement (not really an objection) -- s/suggested value/
value/suggested default value/g suggested default value/g
Also Also
s/shall apply the same jitter/may apply the same jitter/ (to each of s/shall apply the same jitter/may apply the same jitter/ (to each of
these quantities regardless of ...). these quantities regardless of ...).
s/jitter will not be applied/jitter need not be configured/ (on a s/jitter will not be applied/jitter need not be configured/ (on a
"per peer" basis). "per peer" basis).
He stated that in Avici's implementation they allow a lot of He stated that in Avici's implementation they allow a lot of
granularity in timer settings, so this reflects current practice. granularity in timer settings, so this reflects current practice.
Curtis also suggested changing the last paragraph: Curtis also suggested changing the last paragraph:
skipping to change at page 12, line 28 skipping to change at page 13, line 18
A new random value should be picked each time the timer is set. The A new random value should be picked each time the timer is set. The
range of the jitter random value MAY be configurable. range of the jitter random value MAY be configurable.
This would make it clear that it is possible to have this timer as This would make it clear that it is possible to have this timer as
configurable and still be within spec. configurable and still be within spec.
Other comments on Yakov's text pointed out that IOS uses 5 seconds as Other comments on Yakov's text pointed out that IOS uses 5 seconds as
the default IBGP MinRouteAdvertisementInterval. the default IBGP MinRouteAdvertisementInterval.
Tom pointed out that there seems to be a discrepancy between this Tom pointed out that there seems to be a discrepancy between this
text and the FSM: The FSM has an OpenDelay timer. And the FSM text and the FSM: The FSM has an OpenDelay timer. And the FSM
suggests a HoldTimer of 4 minutes. suggests a HoldTimer of 4 minutes.
In following up on this issue, Yakov stated: In following up on this issue, Yakov stated:
Here is the final text for the BGP Timers section: Here is the final text for the BGP Timers section:
BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see BGP employs five timers: ConnectRetry (see Section 8), Hold Time (see
Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
(see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see Section
9.2.1.1). 9.2.1.1).
skipping to change at page 13, line 12 skipping to change at page 13, line 50
The suggested default value for the MinRouteAdvertisementInterval is The suggested default value for the MinRouteAdvertisementInterval is
30 seconds. 30 seconds.
An implementation of BGP MUST allow the Hold Time timer to be An implementation of BGP MUST allow the Hold Time timer to be
configurable, and MAY allow the other timers to be configurable. configurable, and MAY allow the other timers to be configurable.
To minimize the likelihood that the distribution of BGP messages by a To minimize the likelihood that the distribution of BGP messages by a
given BGP speaker will contain peaks, jitter should be applied to the given BGP speaker will contain peaks, jitter should be applied to the
timers associated with MinASOriginationInterval, Keepalive, timers associated with MinASOriginationInterval, Keepalive,
MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker MinRouteAdvertisementInterval, and ConnectRetry. A given BGP speaker
may apply the same jitter to each of these quantities regardless of may apply the same jitter to each of these quantities regardless of
the destinations to which the updates are being sent; that is, jitter the destinations to which the updates are being sent; that is, jitter
need not be configured on a "per peer" basis. need not be configured on a "per peer" basis.
The suggested default amount of jitter shall be determined by The suggested default amount of jitter shall be determined by
multiplying the base value of the appropriate timer by a random multiplying the base value of the appropriate timer by a random
factor which is uniformly distributed in the range from 0.75 to 1.0. factor which is uniformly distributed in the range from 0.75 to 1.0.
A new random value should be picked each time the timer is set. The A new random value should be picked each time the timer is set. The
range of the jitter random value MAY be configurable. range of the jitter random value MAY be configurable.
With this in mind, I would suggest we mark this issue as closed. With this in mind, I would suggest we mark this issue as closed.
Jonathan suggested adding "per peer" to the text, Yakov responded Jonathan suggested adding "per peer" to the text, Yakov responded
with this text: with this text:
An implementation of BGP MUST allow the Hold Time timer to be An implementation of BGP MUST allow the Hold Time timer to be
configurable on a per peer basis, and MAY allow the other timers to configurable on a per peer basis, and MAY allow the other timers to
be configurable. be configurable.
This proposal met with general agreement. This issue is at This proposal met with general agreement. This issue is at
consensus. consensus.
2.9 Reference to RFC904 - EGP Protocol 2.9. Reference to RFC904 - EGP Protocol
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add a reference to RFC904 Summary: Add a reference to RFC904
Discussion: Discussion:
The "Review Comment: Origin Attribute pg 14" thread suggested adding The "Review Comment: Origin Attribute pg 14" thread suggested adding
a reference to RFC904(?), to refer to the EGP protocol. There was no a reference to RFC904(?), to refer to the EGP protocol. There was no
discussion. discussion.
Yakov agreed to this, and Jonathan seconded it. Yakov agreed to this, and Jonathan seconded it.
2.10 Extending AS_PATH Attribute 2.10. Extending AS_PATH Attribute
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add this to 9.2: Summary: Add this to 9.2:
If due to the limits on the maximum size of an UPDATE message (see 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 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 speaker MUST not advertise the route to its peers and may choose to
log an error locally. log an error locally.
skipping to change at page 14, line 24 skipping to change at page 15, line 13
The "Extending AS_PATH attribute length en route" thread brought up The "Extending AS_PATH attribute length en route" thread brought up
the issue of what action should we specify when we receive a route the issue of what action should we specify when we receive a route
with an AS_PATH that exceeds the defined maximum length. There was with an AS_PATH that exceeds the defined maximum length. There was
some discussion, and it was suggested that, after logging the error, some discussion, and it was suggested that, after logging the error,
the route not be propagated. the route not be propagated.
Yakov stated that: Yakov stated that:
The real issue here is how to handle the case when a route (a single The real issue here is how to handle the case when a route (a single
address prefix + path attributes) doesn't fit into 4K bytes (as the address prefix + path attributes) doesn't fit into 4K bytes (as the
max BGP message size is 4 K). To address this issue I would suggest max BGP message size is 4 K). To address this issue I would suggest
to add the following to 9.2: to add the following to 9.2:
After some discussion, Yakov's proposed text's last sentence was After some discussion, Yakov's proposed text's last sentence was
dropped and we arrived at: dropped and we arrived at:
If due to the limits on the maximum size of an UPDATE message (see 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 Section 4) a single route doesn't fit into the message, the BGP
speaker may choose not to advertise the route to its peers. speaker may choose not to advertise the route to its peers.
In response to Andrew's clarification question to the list, Curtis In response to Andrew's clarification question to the list, Curtis
skipping to change at page 15, line 16 skipping to change at page 16, line 5
So the text on the table right now is: So the text on the table right now is:
If due to the limits on the maximum size of an UPDATE message (see 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 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 speaker MUST not advertise the route to its peers and may choose to
log an error locally. log an error locally.
This met with one agreement and no disagreements. We have a This met with one agreement and no disagreements. We have a
consensus. consensus.
2.11 Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add this text: Summary: Add this text:
The local speaker SHALL then install that route in the Loc-RIB, The local speaker SHALL then install that route in the Loc-RIB,
replacing any route to the same destination that is currently being replacing any route to the same destination that is currently being
held in the Loc-RIB. When the new BGP route is installed in the Rout- held in the Loc-RIB. When the new BGP route is installed in the
ing Table, care must be taken to ensure that existing routes to the Rout- ing Table, care must be taken to ensure that existing routes to
same destination that are now considered invalid are removed from the the same destination that are now considered invalid are removed from
Routing Table. Whether or not the new BGP route replaces an existing the Routing Table. Whether or not the new BGP route replaces an
non-BGP route in the Routing Table depends on the policy configured existing non-BGP route in the Routing Table depends on the policy
on the BGP speaker. configured on the BGP speaker.
Discussion: Discussion:
The "Proxy: comments on section 9.1.3" thread brought up some lack of The "Proxy: comments on section 9.1.3" thread brought up some lack of
clarity in the section discussing the rules for which routes get clarity in the section discussing the rules for which routes get
propagated from the Loc-RIB into the Adj-RIB-Out. These discussions propagated from the Loc-RIB into the Adj-RIB-Out. These discussions
resulted in a number of suggestions for new text. resulted in a number of suggestions for new text.
The first new text was proposed to clarify the issue that the thread The first new text was proposed to clarify the issue that the thread
first brought up: first brought up:
I agree that this could use some clarification. How about adding I agree that this could use some clarification. How about adding to
to b) in section 9.1: b) in section 9.1:
The Loc-RIB must contain only one route per destination; further, it The Loc-RIB must contain only one route per destination; further, it
must include all routes that the BGP speaker is using. must include all routes that the BGP speaker is using.
changing c) in section 9.1.2 to: changing c) in section 9.1.2 to:
c) is selected as a result of the Phase 2 tie breaking rules c) is selected as a result of the Phase 2 tie breaking rules
specified in 9.1.2.2, or specified in 9.1.2.2, or
and adding and adding
d) when routing protocols other than BGP are in use, is determined by d) when routing protocols other than BGP are in use, is determined by
some other local means to be the route that will actually be used to some other local means to be the route that will actually be used to
reach a particular destination. reach a particular destination.
This text was never discussed or a consensus formed on putting it in This text was never discussed or a consensus formed on putting it in
the document. the document.
This modification to 9.1.2 was also proposed to address the same This modification to 9.1.2 was also proposed to address the same
skipping to change at page 16, line 20 skipping to change at page 17, line 9
This text was never discussed or a consensus formed on putting it in This text was never discussed or a consensus formed on putting it in
the document. the document.
This modification to 9.1.2 was also proposed to address the same This modification to 9.1.2 was also proposed to address the same
concern: concern:
How about changing the paragraph after c) in 9.1.2 to: How about changing the paragraph after c) in 9.1.2 to:
The local speaker SHALL then install that route in the Loc-RIB, The local speaker SHALL then install that route in the Loc-RIB,
replacing any route to the same destination that is currently being replacing any route to the same destination that is currently being
held in the Loc-RIB. This route SHALL then also be installed in the held in the Loc-RIB. This route SHALL then also be installed in the
BGP speakers forwarding table. BGP speakers forwarding table.
There was one response in the negative to this change, arguing that There was one response in the negative to this change, arguing that
is is not necessary. is is not necessary.
Yakov replied to this that: Yakov replied to this that:
Wrt "adding to b) in section 9.1", the second part (after ";") is Wrt "adding to b) in section 9.1", the second part (after ";") is
redundant as this point is already stated in 3.2. Wrt the first point redundant as this point is already stated in 3.2. Wrt the first
about Loc-RIB containing just one route per destination, I would point about Loc-RIB containing just one route per destination, I
suggest to add it to section 3.2, where Loc-RIB is first introduced, would suggest to add it to section 3.2, where Loc-RIB is first
rather than adding it to 9.1. introduced, rather than adding it to 9.1.
Wrt "changing c)... and adding...", I have no objections to Wrt "changing c)... and adding...", I have no objections to add/
add/modify the text, as suggested above. modify the text, as suggested above.
I am not sure though that changing the paragraph after c) in 9.1.2 is I am not sure though that changing the paragraph after c) in 9.1.2 is
really necessary though, so I would prefer to keep it as is. really necessary though, so I would prefer to keep it as is.
The "issue 11" thread this was being discussed in then digressed to The "issue 11" thread this was being discussed in then digressed to
the topic, now covered in issue 11.3. the topic, now covered in issue 11.3.
Ben re-addressed the original issue with this input: Ben re-addressed the original issue with this input:
I have somewhat of an issue with the paragraph after item c section I have somewhat of an issue with the paragraph after item c section
9.1.2 as discussed. 9.1.2 as discussed.
which is => which is =>
"The local speaker SHALL then install that route in the Loc-RIB, "The local speaker SHALL then install that route in the Loc-RIB,
replacing any route to the same destination that is currently being replacing any route to the same destination that is currently being
held in the Loc-RIB. If the new BGP route is installed in the Routing held in the Loc-RIB. If the new BGP route is installed in the
Table (as a result of the local policy decision), care must be taken Routing Table (as a result of the local policy decision), care must
to ensure that invalid BGP routes to the same destination are removed be taken to ensure that invalid BGP routes to the same destination
from the Routing Table. Whether or not the new route replaces an are removed from the Routing Table. Whether or not the new route
already existing non-BGP route in the routing table depends on the replaces an already existing non-BGP route in the routing table
policy configured on the BGP speaker." depends on the policy configured on the BGP speaker."
Can we assume that its OK to have a route present in the Loc-RIB and Can we assume that its OK to have a route present in the Loc-RIB and
possibly in the adj-RIB-Out but not in the Routing table due to some possibly in the adj-RIB-Out but not in the Routing table due to some
policy. Won't we violate rule number 1? Only advertise what you use. policy. Won't we violate rule number 1? Only advertise what you
use.
As conversely implied in this sentence => As conversely implied in this sentence =>
"If the new BGP route is installed in the Routing Table (as a result "If the new BGP route is installed in the Routing Table (as a result
of the local policy decision), care must be taken to ensure that of the local policy decision), care must be taken to ensure that
invalid BGP routes to the same destination are removed from the invalid BGP routes to the same destination are removed from the
Routing Table" Routing Table"
I would rephrase the paragraph as follows => I would rephrase the paragraph as follows =>
"The local speaker SHALL then install that route in the Loc-RIB, "The local speaker SHALL then install that route in the Loc-RIB,
replacing any route to the same destination that is currently being replacing any route to the same destination that is currently being
held in the Loc-RIB. When the new BGP route is installed in the held in the Loc-RIB. When the new BGP route is installed in the
Routing Table, care must be taken to ensure that existing routes to Routing Table, care must be taken to ensure that existing routes to
the same destination that are now considered invalid are removed from the same destination that are now considered invalid are removed from
the Routing Table. Whether or not the new BGP route replaces an the Routing Table. Whether or not the new BGP route replaces an
existing non-BGP route in the routing table depends on the policy existing non-BGP route in the routing table depends on the policy
configured on the BGP speaker." configured on the BGP speaker."
Jeff replied: Jeff replied:
With the exception that Routing Table should be capitalized With the exception that Routing Table should be capitalized
throughout, I'd suggest we take this as consensus. throughout, I'd suggest we take this as consensus.
Yakov agreed. We are at consensus. Yakov agreed. We are at consensus.
2.11.1 Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3 2.11.1. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: The text below will be added to the -18 version. Summary: The text below will be added to the -18 version.
Discussion: Discussion:
In further discussions around this issue, this text was also In further discussions around this issue, this text was also
proposed: proposed:
skipping to change at page 18, line 14 skipping to change at page 19, line 5
Any local-policy which results in reachability being added to an Adj- Any local-policy which results in reachability being added to an Adj-
RIB-Out without also being added to the local BGP speaker's RIB-Out without also being added to the local BGP speaker's
forwarding table is beyond the scope of this document. forwarding table is beyond the scope of this document.
This suggestion received one response that agreed to this change. This suggestion received one response that agreed to this change.
This text will be added to the -18 version, and since there were no This text will be added to the -18 version, and since there were no
objections, this issue has been moved to consensus. objections, this issue has been moved to consensus.
2.11.2 Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2 2.11.2. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add this text: Summary: Add this text:
In the context of this document we assume that a BGP speaker In the context of this document we assume that a BGP speaker
advertises to its peers only those routes that it itself uses (in advertises to its peers only those routes that it itself uses (in
this context a BGP speaker is said to "use" a BGP route if it is the this context a BGP speaker is said to "use" a BGP route if it is the
most preferred BGP route and is used in forwarding). All other cases most preferred BGP route and is used in forwarding). All other cases
are outside the scope of this document. are outside the scope of this document.
Discussion: Discussion:
Additionally this thread produced this section of new text, in Additionally this thread produced this section of new text, in
section 2: section 2:
<OLD> <OLD>
"one must focus on the rule that a BGP speaker advertises to its "one must focus on the rule that a BGP speaker advertises to its
skipping to change at page 18, line 49 skipping to change at page 19, line 40
<NEW #1> <NEW #1>
"one must focus on the rule that a BGP speaker advertises to its "one must focus on the rule that a BGP speaker advertises to its
peers (other BGP speakers which it communicates with) in neighboring peers (other BGP speakers which it communicates with) in neighboring
ASs only routes whose NLRIs are locally reachable." ASs only routes whose NLRIs are locally reachable."
<NEW #2> <NEW #2>
"one must focus on the rule that a BGP speaker advertises to its "one must focus on the rule that a BGP speaker advertises to its
peers (other BGP speakers which it communicates with) in neighboring peers (other BGP speakers which it communicates with) in neighboring
ASs only routes which are locally reachable. Local reachability can ASs only routes which are locally reachable. Local reachability can
be achieved by having any protocol route to the given destination in be achieved by having any protocol route to the given destination in
the routing table." the routing table."
There were a lot of emails exchanged on this topic with a variety of There were a lot of emails exchanged on this topic with a variety of
texts proposed (see early in the "Active Route" thread). This issue texts proposed (see early in the "Active Route" thread). This issue
reopened with Jonathan, who brought up the issue originally, stating reopened with Jonathan, who brought up the issue originally, stating
that: that:
The issue I raised, and would like to be [re-]considered is with: The issue I raised, and would like to be [re-]considered is with:
"one must focus on the rule that a BGP speaker advertises to its "one must focus on the rule that a BGP speaker advertises to its
peers (other BGP speakers which it communicates with) in neighboring peers (other BGP speakers which it communicates with) in neighboring
ASs only those routes that it itself uses." ASs only those routes that it itself uses."
skipping to change at page 20, line 39 skipping to change at page 19, line 127
Of course looking at what we ended up with, I'd also go along with Of course looking at what we ended up with, I'd also go along with
the other two options (leave it out or put the one sentence in a the other two options (leave it out or put the one sentence in a
separate paragraph as is). separate paragraph as is).
After some additional discussion (in the "issue 11.2" thread), we After some additional discussion (in the "issue 11.2" thread), we
have come to a consensus on this text: have come to a consensus on this text:
In the context of this document we assume that a BGP speaker In the context of this document we assume that a BGP speaker
advertises to its peers only those routes that it itself uses (in advertises to its peers only those routes that it itself uses (in
this context a BGP speaker is said to "use" a BGP route if it is the this context a BGP speaker is said to "use" a BGP route if it is the
most preferred BGP route and is used in forwarding). All other cases most preferred BGP route and is used in forwarding). All other cases
are outside the scope of this document. are outside the scope of this document.
This issue is at consensus. This issue is at consensus.
2.11.3 Documenting IBGP Multipath 2.11.3. Documenting IBGP Multipath
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: The documenting of IBGP Multipath is left to another Summary: The documenting of IBGP Multipath is left to another
Internet Draft. The consensus is that it should not be in the base Internet Draft. The consensus is that it should not be in the base
spec. spec.
Discussion: Discussion:
This thread began in the "issue 11" discussion. In it it was This thread began in the "issue 11" discussion. In it it was
proposed that: proposed that:
There is support in some router vendors to allow more than one BGP There is support in some router vendors to allow more than one BGP
route to be installed, for the purpose for load balancing. Given that route to be installed, for the purpose for load balancing. Given
this is a current practice, and seems to be a useful feature as well, that this is a current practice, and seems to be a useful feature as
should we insist that only one route be installed in the Loc-RIB ? well, should we insist that only one route be installed in the Loc-
RIB ?
I would like to suggest that all sections which use MUST in the I would like to suggest that all sections which use MUST in the
context of only one route in Loc-RIB be relaxed a little to a SHOULD, context of only one route in Loc-RIB be relaxed a little to a SHOULD,
and a section added that states that it is possible for a n and a section added that states that it is possible for a n
implementation to add more than one route to the Loc-RIB for the implementation to add more than one route to the Loc-RIB for the
purposes of load balancing. purposes of load balancing.
While it will be useful to describe how this situation is the While it will be useful to describe how this situation is the
handler, it is perhaps sufficient to even state that handling of this handler, it is perhaps sufficient to even state that handling of this
situation is outside the scope of this RFC. situation is outside the scope of this RFC.
I am including some proposed text for this purpose: I am including some proposed text for this purpose:
For the part: For the part:
> The Loc-RIB must contain only one route per destination; > The Loc-RIB must contain only one route per destination;
consider instead, consider instead,
% The Loc-RIB SHOULD contain only one route per destination. % An % The Loc-RIB SHOULD contain only one route per destination. % An
implementation may choose to install multiple routes to % a implementation may choose to install multiple routes to % a
destination (for the purposes of load balancing). The % handling of destination (for the purposes of load balancing). The % handling of
such a configuration, however, is outside the % scope of this RFC. such a configuration, however, is outside the % scope of this RFC.
Perhaps, this can be in section 3.2 instead. Perhaps, this can be in section 3.2 instead.
After much discussion back and forth, it was agreed that documenting After much discussion back and forth, it was agreed that documenting
IBGP Multipath behavior is a good thing. However, it is something IBGP Multipath behavior is a good thing. However, it is something
that belongs in another draft. that belongs in another draft.
Alex opened this issue up again. There were a flurry of responses, Alex opened this issue up again. There were a flurry of responses,
most all of them agreeing with the original consensus that we should most all of them agreeing with the original consensus that we should
skipping to change at page 24, line 18 skipping to change at page 19, line 300
Section 9.1.2.2. Some relaxation of the "equal cost" rule (also Section 9.1.2.2. Some relaxation of the "equal cost" rule (also
applicable to IGP multipath) is possible. In addition to the equal applicable to IGP multipath) is possible. In addition to the equal
cost BGP NEXT_HOPS available at BGP route selection, if the IGP next cost BGP NEXT_HOPS available at BGP route selection, if the IGP next
hop for other BGP NEXT_HOPs are of lower cost, then those may be used hop for other BGP NEXT_HOPs are of lower cost, then those may be used
as well. This relaxation of the step "e" is possible but is not as well. This relaxation of the step "e" is possible but is not
widely implemented (and may not be implemented at all). widely implemented (and may not be implemented at all).
The consensus of the majority of the IDR WG is to keep this in a The consensus of the majority of the IDR WG is to keep this in a
separate draft and out of the base spec. separate draft and out of the base spec.
2.12 TCP Behavior Wording 2.12. TCP Behavior Wording
Status: Consensus Status: Consensus
Change: No Change: No
Summary: In issue 19 we decided to remove this section entirely. As Summary: In issue 19 we decided to remove this section entirely. As
a result the previous consensus on this issue (no change) is needed a result the previous consensus on this issue (no change) is needed
moot. moot.
Discussion: The subject-less "your mail" thread discussed a wording Discussion: The subject-less "your mail" thread discussed a wording
clarification from: clarification from:
skipping to change at page 24, line 41 skipping to change at page 19, line 323
bytes) per peer and fill it with data as available until a complete bytes) per peer and fill it with data as available until a complete
message has been received. " message has been received. "
To something that is more TCP-correct, such as: To something that is more TCP-correct, such as:
"An implementation that would "hang" the routing information process "An implementation that would "hang" the routing information process
while trying to received from a peer could set up a message buffer while trying to received from a peer could set up a message buffer
(4096 bytes) per peer and fill it with data as available until a (4096 bytes) per peer and fill it with data as available until a
complete message has been received. " complete message has been received. "
(only change: "read" to "received" This was one of a couple of (only change: "read" to "received" This was one of a couple of
suggested changes.) suggested changes.)
This suggestion was quite contentious, and although there were a This suggestion was quite contentious, and although there were a
variety of alternate texts proposed, the only consensus was that this variety of alternate texts proposed, the only consensus was that this
was a very minor issue, and probably not worth changing. was a very minor issue, and probably not worth changing.
In issue 19 we decided to remove this section entirely. In issue 19 we decided to remove this section entirely.
2.13 Next Hop for Originated Route 2.13. Next Hop for Originated Route
Status: Consensus Status: Consensus
Change: No Change: No
Summary: No responses, assumed consensus to keep things the same. Summary: No responses, assumed consensus to keep things the same.
Discussion: Discussion:
There was a one-message thread entitled "next hop for originated There was a one-message thread entitled "next hop for originated
route". This message received no response, so the assumption is that route". This message received no response, so the assumption is that
there is a consensus to keep things as they are. there is a consensus to keep things as they are.
For related discussion see issue 61. For related discussion see issue 61.
2.14 NEXT_HOP to Internal Peer 2.14. NEXT_HOP to Internal Peer
Status: Consensus Status: Consensus
Change: No Change: No
Summary: Closed in favor of issue 61. Summary: Closed in favor of issue 61.
Discussion: Discussion:
The thread entitled "NEXT_HOP to internal peer" starts with this The thread entitled "NEXT_HOP to internal peer" starts with this
question: question:
When sending a locally originated route to an internal peer, what When sending a locally originated route to an internal peer, what
should NEXT_HOP be set to? should NEXT_HOP be set to?
One response suggested that we add a line stating that the NEXT_HOP One response suggested that we add a line stating that the NEXT_HOP
address originates from the IGP. address originates from the IGP.
Since this issue and issue 61 are basically the same, except 61 Since this issue and issue 61 are basically the same, except 61
proposes text, we'll close this issue in favor of 61. proposes text, we'll close this issue in favor of 61.
2.15 Grammar Fix 2.15. Grammar Fix
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Change: "The Prefix field contains IP address prefixes ..." Summary: Change: "The Prefix field contains IP address prefixes ..."
To: "contains an IP address prefix ..." To: "contains an IP address prefix ..."
Discussion: The thread entitled "Review comment: bottom of page 16" Discussion: The thread entitled "Review comment: bottom of page 16"
corrects a grammar mistake by suggesting we change: corrects a grammar mistake by suggesting we change:
"The Prefix field contains IP address prefixes ..." "The Prefix field contains IP address prefixes ..."
skipping to change at page 26, line 4 skipping to change at page 19, line 381
To: "contains an IP address prefix ..." To: "contains an IP address prefix ..."
Discussion: The thread entitled "Review comment: bottom of page 16" Discussion: The thread entitled "Review comment: bottom of page 16"
corrects a grammar mistake by suggesting we change: corrects a grammar mistake by suggesting we change:
"The Prefix field contains IP address prefixes ..." "The Prefix field contains IP address prefixes ..."
to: to:
"contains an IP address prefix ..." "contains an IP address prefix ..."
Yakov responded that this will be fixed in -18. Yakov responded that this will be fixed in -18.
The consensus seems to be to correct this, and go with the new text. The consensus seems to be to correct this, and go with the new text.
2.16 Need ToC, Glossary and Index 2.16. Need ToC, Glossary and Index
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Need to add a Table of Contents (ToC), Glossary and Index to Summary: Need to add a Table of Contents (ToC), Glossary and Index to
the draft. Will be added in draft -18. the draft. Will be added in draft -18.
Discussion: Discussion:
The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests: The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests:
1. Document needs, Table of Contents, Glossary, and Index 1. Document needs, Table of Contents, Glossary, and Index
2. Paths, Routes, and Prefixes need to be defined in the spec early 2. Paths, Routes, and Prefixes need to be defined in the spec early
on (like in a glossary), so it is obvious what is implied. on (like in a glossary), so it is obvious what is implied.
Yakov responded that draft -18 will have a ToC and definition of Yakov responded that draft -18 will have a ToC and definition of
commonly used terms. commonly used terms.
2.17 Add References to other RFC-status BGP docs to base spec. 2.17. Add References to other RFC-status BGP docs to base spec
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add references to other RFC-status BGP docs to the base Summary: Add references to other RFC-status BGP docs to the base
spec. spec.
Discussion: Discussion:
The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes
titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to
suggest: suggest:
3. All BGP Extensions described in other documents that made it to 3. All BGP Extensions described in other documents that made it to
RFC status should be at least referenced in the Reference section RFC status should be at least referenced in the Reference section
P.64. This is justifiable since it's the core BGP standard spec. P.64. This is justifiable since it's the core BGP standard spec.
Yakov responded that this will be added to the -18 review. Yakov responded that this will be added to the -18 review.
Jonathan agreed. Jonathan agreed.
2.18 IP Layer Fragmentation 2.18. IP Layer Fragmentation
Status: Consensus Status: Consensus
Change: No Change: No
Summary: No need to mention IP Layer Fragmentation in the BGP Summary: No need to mention IP Layer Fragmentation in the BGP
specification, since this is taken care of at the TCP level. specification, since this is taken care of at the TCP level.
Discussion: Discussion:
1. P.6 section 4. Message Formats, its possible for the source BGP 1. P.6 section 4. Message Formats, its possible for the source BGP
peer IP layer to fragment a message such that the receiving BGP peer peer IP layer to fragment a message such that the receiving BGP peer
socket layer would have to reassemble it. Need to mention this, since socket layer would have to reassemble it. Need to mention this,
BGP implementations are required to do this. since BGP implementations are required to do this.
The response to this was that, while true, reassembly is something The response to this was that, while true, reassembly is something
that is inherent in the TCP layer that BGP rides over. Therefore, that is inherent in the TCP layer that BGP rides over. Therefore,
this is something that is in the TCP spec, and needn't be repeated in this is something that is in the TCP spec, and needn't be repeated in
the BGP spec. This comment was reaffirmed. There seems to be the BGP spec. This comment was reaffirmed. There seems to be
consensus that this isn't something that needs to be in the BGP spec. consensus that this isn't something that needs to be in the BGP spec.
2.19 Appendix Section 6.2: Processing Messages on a Stream Protocol 2.19. Appendix Section 6.2: Processing Messages on a Stream Protocol
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Remove the section entirely, as this is something that does Summary: Remove the section entirely, as this is something that does
not belong in the base spec. not belong in the base spec.
Discussion: Discussion:
This first came up in response to Issue 17: This first came up in response to Issue 17:
skipping to change at page 27, line 43 skipping to change at page 19, line 469
The original reviewer responded that the out-of-scope comment was The original reviewer responded that the out-of-scope comment was
out-of-place and referred the responder to section 6.2 (appendix 6) out-of-place and referred the responder to section 6.2 (appendix 6)
The original reviewer stated that he is happy with just adding a The original reviewer stated that he is happy with just adding a
reference to section 6.2 in appendix 6 and leaving it at that. reference to section 6.2 in appendix 6 and leaving it at that.
Curtis suggested we just add a reference to Stevens in appendix 6. Curtis suggested we just add a reference to Stevens in appendix 6.
6.2 and be done with it. Specifically: 6.2 and be done with it. Specifically:
6.2 Processing Messages on a Stream Protocol 6.2 Processing Messages on a Stream Protocol
BGP uses TCP as a transport mechanism. If you are unsure as to how BGP uses TCP as a transport mechanism. If you are unsure as to how
to handle asynchronous reads and writes on TCP sockets please refer to handle asynchronous reads and writes on TCP sockets please refer
to Unix Network Programming [RWStevens] or other introductory text to Unix Network Programming [RWStevens] or other introductory text
for programming techniques for the operating system and TCP for programming techniques for the operating system and TCP
implementation that you are using. implementation that you are using.
There were further suggestions to remove the section entirely as out- There were further suggestions to remove the section entirely as out-
of-scope. At least 3 people agreed with this. of-scope. At least 3 people agreed with this.
Alex responded that he sees no reason to remove it, but wouldn't have Alex responded that he sees no reason to remove it, but wouldn't have
a problem if the WG decides to do so. a problem if the WG decides to do so.
There seems to be general agreement that this section should be There seems to be general agreement that this section should be
removed. removed.
N.B. This also affects issue 12. N.B. This also affects issue 12.
2.20 Wording fix in Section 4.3 2.20. Wording fix in Section 4.3
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: A small change for clarity in section 4.3 Summary: A small change for clarity in section 4.3
Discussion: Discussion:
This suggestion grew out of the discussion on Issue 18. This suggestion grew out of the discussion on Issue 18.
The following change was suggested in section 4.3, second line of the The following change was suggested in section 4.3, second line of the
first paragraph: first paragraph:
s/UPDATE packet/UPDATE message/ s/UPDATE packet/UPDATE message/
Yakov agreed to this change and updated the draft. Yakov agreed to this change and updated the draft.
2.21 Authentication Text Update 2.21. Authentication Text Update
Status: Consensus Status: Consensus
Change: No Change: No
Summary: The consensus is that additional references to RFC2385 are Summary: The consensus is that additional references to RFC2385 are
not necessary. not necessary.
Discussion: Discussion:
P. 10, "Authentication Data:" section you might want to add this, It P. 10, "Authentication Data:" section you might want to add this, It
is also possible to use MD5 (RFC2385) at the transport layer to is also possible to use MD5 (RFC2385) at the transport layer to
validate the entire BGP message. validate the entire BGP message.
Yakov replied to this: Yakov replied to this:
There is already text that covers this: There is already text that covers this:
"Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may
be used in addition to BGP's own authentication mechanisms." be used in addition to BGP's own authentication mechanisms."
.... ....
"In addition, BGP supports the ability to authenticate its data "In addition, BGP supports the ability to authenticate its data
stream by using [RFC2385]." stream by using [RFC2385]."
So, I see no need to add the text proposed above. So, I see no need to add the text proposed above.
Ishi agreed with Yakov. Jonathan disagreed since he thought no one Ishi agreed with Yakov. Jonathan disagreed since he thought no one
uses BGP auth. Ishi replied that there are lots of people who do use uses BGP auth. Ishi replied that there are lots of people who do use
it. Jonathan replied with a clarification question: "Who uses *BGP's it. Jonathan replied with a clarification question: "Who uses *BGP's
own* authentication mechanisms???" Ron Bonica replied that they use own* authentication mechanisms???" Ron Bonica replied that they use
skipping to change at page 29, line 25 skipping to change at page 19, line 547
simple password authentication vs. MD5. simple password authentication vs. MD5.
After further discussion, the consensus seems to be that we should After further discussion, the consensus seems to be that we should
leave the text as it is for the reasons Yakov pointed out. There was leave the text as it is for the reasons Yakov pointed out. There was
some discussion over opening a new issue to discuss deprecating the some discussion over opening a new issue to discuss deprecating the
BGP auth mechanism discussed in RFC1771 in favor of the mechanism in BGP auth mechanism discussed in RFC1771 in favor of the mechanism in
RFC2385. RFC2385.
The issue of Deprecating BGP AUTH is discussed in issue 62. The issue of Deprecating BGP AUTH is discussed in issue 62.
2.22 Scope of Path Attribute Field 2.22. Scope of Path Attribute Field
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: This is already being covered by text that has been added to Summary: This is already being covered by text that has been added to
the -18 draft. the -18 draft.
Discussion: Discussion:
P. 12, right after "Path Attributes". The following sentence should P. 12, right after "Path Attributes". The following sentence should
be added to this section to clarify the scope of the Path Attribute be added to this section to clarify the scope of the Path Attribute
field. "All attributes in the Path Attribute field represent the field. "All attributes in the Path Attribute field represent the
characteristics of all the route prefixes defined in the NLRI field characteristics of all the route prefixes defined in the NLRI field
of the message". of the message".
Yakov replied to this that: Yakov replied to this that:
This will be covered by the following text in 3.1 that will be in the This will be covered by the following text in 3.1 that will be in the
-18 version (see also issue 54). -18 version (see also issue 54).
Routes are advertised between BGP speakers in UPDATE messages. Routes are advertised between BGP speakers in UPDATE messages.
Multiple routes that have the same path attributes can be advertised Multiple routes that have the same path attributes can be advertised
in a single UPDATE message by including multiple prefixes in the NLRI in a single UPDATE message by including multiple prefixes in the NLRI
field of the UPDATE message. field of the UPDATE message.
Therefore there is no need to add the sentence proposed above. Therefore there is no need to add the sentence proposed above.
There were no objections to this statement, so this issue has been There were no objections to this statement, so this issue has been
moved into consensus. moved into consensus.
2.23 Withdrawn and Updated routes in the same UPDATE message 2.23. Withdrawn and Updated routes in the same UPDATE message
Status: Consensus Status: Consensus
Change: No Change: No
Summary: For various reasons, not least of which is compatibility Summary: For various reasons, not least of which is compatibility
with existing implementations, the decision was made to keep thing with existing implementations, the decision was made to keep thing
the way they are. the way they are.
Discussion: Discussion:
4. P.16, last paragraph in section 4.3 as stated, "An UPDATE message 4. P.16, last paragraph in section 4.3 as stated, "An UPDATE message
should not include the same address prefix in the WITHDRAWN ROUTES should not include the same address prefix in the WITHDRAWN ROUTES
and Network Layer Reachability Information fields, however a BGP and Network Layer Reachability Information fields, however a BGP
speaker MUST be able to process UPDATE messages in this form. A BGP speaker MUST be able to process UPDATE messages in this form. A BGP
speaker should treat an UPDATE message of this form as if the speaker should treat an UPDATE message of this form as if the
WITHDRAWN ROUTES doesn't contain the address prefix." WITHDRAWN ROUTES doesn't contain the address prefix."
This complexity could have been avoided if withdrawn routes and NLRI This complexity could have been avoided if withdrawn routes and NLRI
prefixes with their attributes were mutually exclusive of each other prefixes with their attributes were mutually exclusive of each other
and appeared in different update messages. If that was the case, the and appeared in different update messages. If that was the case, the
priority of which field to process first would have been as simple as priority of which field to process first would have been as simple as
using "first come, first served" message processing approach. using "first come, first served" message processing approach.
Yakov commented that this would make the case where they are both in Yakov commented that this would make the case where they are both in
the same message unspecified. the same message unspecified.
John commented that this is something we don't want to change this John commented that this is something we don't want to change this
late in the game. Although it was acknowledged that this might be a late in the game. Although it was acknowledged that this might be a
good change if we were working from a clean slate. good change if we were working from a clean slate.
skipping to change at page 31, line 20 skipping to change at page 19, line 638
this was a good way to say "delete then add".] this was a good way to say "delete then add".]
Process UPDATEs from the same peer in the order received. Process UPDATEs from the same peer in the order received.
And goes on to say, that to him, these rules are clear from the And goes on to say, that to him, these rules are clear from the
existing text. existing text.
Consensus is that while this would be nice, we need to stick with Consensus is that while this would be nice, we need to stick with
what we have, and move on. what we have, and move on.
2.24 Addition or Deletion of Path Attributes 2.24. Addition or Deletion of Path Attributes
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add the following to section 3.1: Summary: Add the following to section 3.1:
Changing the attributes of a route is accomplished by advertising a Changing the attributes of a route is accomplished by advertising a
replacement route. The replacement route carries new (changed) replacement route. The replacement route carries new (changed)
attributes and has the same NLRI as the original route. attributes and has the same NLRI as the original route.
Discussion: Discussion:
5. P. 20 Its not stated how we delete or modify Path Attributes 5. P. 20 Its not stated how we delete or modify Path Attributes
associated with NLRI prefixes. associated with NLRI prefixes.
A response to this comment said that this is implicit in the A response to this comment said that this is implicit in the
definition of "route" and the general withdraw/replace behavior and definition of "route" and the general withdraw/replace behavior and
therefore doesn't need to be repeated. therefore doesn't need to be repeated.
Ben responded saying that, while there was an assumption, there was Ben responded saying that, while there was an assumption, there was
no well defined mechanism, and this leads to ambiguity. no well defined mechanism, and this leads to ambiguity.
John responded, no need to define everything explicitly, or we'll be John responded, no need to define everything explicitly, or we'll be
here forever. here forever.
Picking this thread up again, Yakov argued: Picking this thread up again, Yakov argued:
By *definition* a route is a <path attribute, NLRI> pair. From that By *definition* a route is a <path attribute, NLRI> pair. From that
definition it follows that changing one or more path attributes of a definition it follows that changing one or more path attributes of a
route means changing a route, which means withdrawing the old route route means changing a route, which means withdrawing the old route
(route with the old attributes) from service and advertising a new (route with the old attributes) from service and advertising a new
route (route with the new attributes). Procedures for doing this are route (route with the new attributes). Procedures for doing this are
well-defined (see section 3.1), and therefore no new text to cover well-defined (see section 3.1), and therefore no new text to cover
this is needed. this is needed.
Jonathan agreed with this statement, but Ben argued that the text in Jonathan agreed with this statement, but Ben argued that the text in
section 3 is insufficient the way it is currently written. After section 3 is insufficient the way it is currently written. After two
two iterations, Ben and Yakov agreed on this formulation for an iterations, Ben and Yakov agreed on this formulation for an update to
update to section 3.1: section 3.1:
Changing the attributes of a route is accomplished by advertising a Changing the attributes of a route is accomplished by advertising a
replacement route. The replacement route carries new (changed) replacement route. The replacement route carries new (changed)
attributes and has the same NLRI as the original route. attributes and has the same NLRI as the original route.
Jeff objected somewhat to the wording, since, because of a bgp route Jeff objected somewhat to the wording, since, because of a bgp route
is defined as a <path attribute, NLRI> pair, changing either part of is defined as a <path attribute, NLRI> pair, changing either part of
that pair, by definition, changes the route. He acknowledged that that pair, by definition, changes the route. He acknowledged that
this might fall under the category of implementation detail. this might fall under the category of implementation detail.
Yakov presented the view that he thought we were at consensus with Yakov presented the view that he thought we were at consensus with
the text he proposed above. Jonathan agreed. There were no the text he proposed above. Jonathan agreed. There were no
objections, so this is moved to Consensus. objections, so this is moved to Consensus.
2.25 NEXT_HOP Semantics 2.25. NEXT_HOP Semantics
Status: Consensus Status: Consensus
Change: No Change: No
Summary: After responders pointed out another sentence, this comment Summary: After responders pointed out another sentence, this comment
was resolved. Things will stay the way they are. was resolved. Things will stay the way they are.
Discussion: Discussion:
1. P.28, 2nd to last paragraph. The line that reads, "To be 1. P.28, 2nd to last paragraph. The line that reads, "To be
semantically correct, the IP address in the NEXT_HOP must not be the semantically correct, the IP address in the NEXT_HOP must not be the
IP address of the receiving speaker, and the NEXT_HOP IP address must IP address of the receiving speaker, and the NEXT_HOP IP address must
either be the sender's IP address (used to establish the BGP either be the sender's IP address (used to establish the BGP
session), or the interface associated with the NEXT_HOP IP address session), or the interface associated with the NEXT_HOP IP address
must share a common subnet with the receiving BGP speaker..." must share a common subnet with the receiving BGP speaker..."
This is not always true, what if the current ASBR BGP router is This is not always true, what if the current ASBR BGP router is
advertising an external AS route (to a IBGP Peer) whose NEXT_HOP IP advertising an external AS route (to a IBGP Peer) whose NEXT_HOP IP
address is the IP address of the EBGP peer in the other AS? address is the IP address of the EBGP peer in the other AS?
A response to this pointed out that right before this is a sentence A response to this pointed out that right before this is a sentence
stating that this only applied to eBGP links, and only when the peers stating that this only applied to eBGP links, and only when the peers
are one hop from each other, so a modification is unnecessary. This are one hop from each other, so a modification is unnecessary. This
response was confirmed with another. response was confirmed with another.
The original reviewer acknowledged this and withdrew the comment. The original reviewer acknowledged this and withdrew the comment.
The consensus is to leave things the way they are. The consensus is to leave things the way they are.
2.26) Attributes with Multiple Prefixes 2.26. Attributes with Multiple Prefixes
Status: Consensus Status: Consensus
Change: No Change: No
Summary: After some discussion, the consensus is to keep things the Summary: After some discussion, the consensus is to keep things the
same since the suggested behavior is defined in the message format. same since the suggested behavior is defined in the message format.
Discussion: Discussion:
2. P. 29, Section 6.3. Add this rule near the attribute rules. 2. P. 29, Section 6.3. Add this rule near the attribute rules.
"Multiple prefixes that require the same attribute type with "Multiple prefixes that require the same attribute type with
different values must never appear in the same update message". different values must never appear in the same update message".
A response to this suggested that this text is unnecessary since this A response to this suggested that this text is unnecessary since this
behavior is ruled out by the way the message format is defined. behavior is ruled out by the way the message format is defined.
The original commenter agrees with the responder. The consensus is The original commenter agrees with the responder. The consensus is
to leave things the way they are. to leave things the way they are.
2.27 Allow All Non-Destructive Messages to Refresh Hold Timer 2.27. Allow All Non-Destructive Messages to Refresh Hold Timer
Status: Consensus Status: Consensus
Change: No Change: No
Summary: It is agreed that this is a change that exceeds the original Summary: It is agreed that this is a change that exceeds the original
goal of this draft revision. This goal is to document existing goal of this draft revision. This goal is to document existing
practice in an interoperable way. practice in an interoperable way.
Discussion: Discussion:
3. P. 29, Section 6.5, Please rewrite this sentence from: "If a 3. P. 29, Section 6.5, Please rewrite this sentence from: "If a
system does not receive successive KEEPALIVE and/or UPDATE and/or system does not receive successive KEEPALIVE and/or UPDATE and/or
NOTIFICATION messages within the period specified in the Hold Time NOTIFICATION messages within the period specified in the Hold Time
field of the OPEN message ..." field of the OPEN message ..."
To This: "If a system does not receive successive KEEPALIVE and/or To This: "If a system does not receive successive KEEPALIVE and/or
UPDATE and/or any other BGP message within the period specified in UPDATE and/or any other BGP message within the period specified in
the Hold Time field of the OPEN message ..." the Hold Time field of the OPEN message ..."
There is disagreement on this change. It has been discussed in other There is disagreement on this change. It has been discussed in other
threads. threads.
The original commenter acknowledged that this is something that would The original commenter acknowledged that this is something that would
be "adding a new feature" as opposed to the stated goal of be "adding a new feature" as opposed to the stated goal of
"documenting what exists." He suggested that the ADs decide if we "documenting what exists." He suggested that the ADs decide if we
should open the door for new features or not. should open the door for new features or not.
Yakov replied to this that he would suggest we keep things as is, Yakov replied to this that he would suggest we keep things as is,
since the purpose is to document current implementations. since the purpose is to document current implementations.
This did not meet with any objections, so this issue has been moved This did not meet with any objections, so this issue has been moved
into consensus. into consensus.
2.28 BGP Identifier as Variable Quantity 2.28. BGP Identifier as Variable Quantity
Status: Consensus Status: Consensus
Change: No Change: No
Summary: The consensus is that changing the BGP Identifier in the Summary: The consensus is that changing the BGP Identifier in the
base draft is out-of-scope at this point in the draft evolution. base draft is out-of-scope at this point in the draft evolution.
Discussion: Discussion:
4. P. 31, section 6.8, Please rewrite this sentence from: "Comparing 4. P. 31, section 6.8, Please rewrite this sentence from: "Comparing
BGP Identifiers is done by treating them as (4-octet long) unsigned BGP Identifiers is done by treating them as (4-octet long) unsigned
integers." integers."
To This: "Comparing BGP Identifiers is done by treating them as large To This: "Comparing BGP Identifiers is done by treating them as large
numbers based on their IP Address type (e.g. IPv4, IPv6, etc.)." numbers based on their IP Address type (e.g. IPv4, IPv6, etc.)."
A response to this was that since BGP Identifier is defined in the A response to this was that since BGP Identifier is defined in the
base spec as a 4 byte unsigned integer, and not a variable quantity, base spec as a 4 byte unsigned integer, and not a variable quantity,
the sentence as written is acceptable. This was also confirmed by the sentence as written is acceptable. This was also confirmed by
another response. another response.
The original commenter was thinking of IPv6, and providing sufficient The original commenter was thinking of IPv6, and providing sufficient
space to allow a full v6 address to be used. space to allow a full v6 address to be used.
Again, responders said that this is out-of-scope for the current Again, responders said that this is out-of-scope for the current
draft. draft.
2.29 State Why Unresolveable Routes Should Be Kept in Adj-RIB-In 2.29. State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add: Summary: Add:
"in case they become resolvable" after the last sentence on p. 46. "in case they become resolvable" after the last sentence on p. 46.
Discussion: Discussion:
5. P.46, last sentence, "However, corresponding unresolvable routes 5. P.46, last sentence, "However, corresponding unresolvable routes
SHOULD be kept in the Adj-RIBs-In." It would helpful if the author SHOULD be kept in the Adj-RIBs-In." It would helpful if the author
states why unresolvable routes should be kept in Adj-RIBs-In? states why unresolvable routes should be kept in Adj-RIBs-In?
A response to this stated "In case they become resolvable" A response to this stated "In case they become resolvable"
Yakov responded that: Yakov responded that:
I suggest we add "in case they become resolvable" after the last I suggest we add "in case they become resolvable" after the last
sentence on p. 46. sentence on p. 46.
The original commenter stated that: Then the point that the peer will The original commenter stated that: Then the point that the peer will
not refresh the route if we drop them (unless we use Route Refresh) not refresh the route if we drop them (unless we use Route Refresh)
because they are unreachable should be made. because they are unreachable should be made.
Yakov also responded that: Yakov also responded that:
This should be clear from the following text in Section 3: This should be clear from the following text in Section 3:
The initial data flow is the portion of the BGP routing table that is The initial data flow is the portion of the BGP routing table that is
allowed by the export policy, called the Adj-Ribs-Out (see 3.2). allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
Incremental updates are sent as the routing tables change. BGP does Incremental updates are sent as the routing tables change. BGP does
not require periodic refresh of the routing table. not require periodic refresh of the routing table.
Jonathan, who was the original commenter, agreed with both the Jonathan, who was the original commenter, agreed with both the
changed text and the clarity of section 3. changed text and the clarity of section 3.
2.30 Mention Other Message Types 2.30. Mention Other Message Types
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add a reference to RFC2918 at the end of the type code list. Summary: Add a reference to RFC2918 at the end of the type code list.
Discussion: Discussion:
1. P. 7 Type: Need to add the new message types such as, Capability 1. P. 7 Type: Need to add the new message types such as, Capability
Negotiations (RFC2842), Route Refresh, etc. Negotiations (RFC2842), Route Refresh, etc.
One response argued that these are out-of-scope of the base document. One response argued that these are out-of-scope of the base document.
One response agreed, but thought that it should be capability and not One response agreed, but thought that it should be capability and not
message type. The original commenter responded about Message type message type. The original commenter responded about Message type
from the capability draft. from the capability draft.
Sue mentioned this would be added in the second round. Sue mentioned this would be added in the second round.
Yakov replied that: Yakov replied that:
The only new message type that is covered by an RFC (rather than just The only new message type that is covered by an RFC (rather than just
an Internet Draft) is the Refresh message. With this in mind how an Internet Draft) is the Refresh message. With this in mind how
about replacing the following: about replacing the following:
The following type codes are defined: The following type codes are defined:
1 - OPEN 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
with with
This document defines the following type codes: This document defines the following type codes:
1 - OPEN 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
[RFC2918] defines one more type code. [RFC2918] defines one more type code.
Jonathan agreed with this change. This issue has been moved to Jonathan agreed with this change. This issue has been moved to
consensus. consensus.
2.31 Add References to Additional Options 2.31. Add References to Additional Options
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Consensus to add: Summary: Consensus to add:
[RFC2842] defines another Optional Parameter. [RFC2842] defines another Optional Parameter.
Discussion: Discussion:
2. P. 9, right after "This document defines the following optional 2. P. 9, right after "This document defines the following optional
parameters:" Need to mention possible options, such as: Capabilities parameters:" Need to mention possible options, such as: Capabilities
(RFC2842), Multiprotocol extensions (RFC2858), Route Refresh (RFC2842), Multiprotocol extensions (RFC2858), Route Refresh
(RFC2918). (RFC2918).
One response agreed that adding references would be fine. A second One response agreed that adding references would be fine. A second
response agreed. response agreed.
Yakov replied that: Yakov replied that:
Please note that only rfc2842 defines an OPEN optional parameter. Please note that only rfc2842 defines an OPEN optional parameter.
Neither rfc2858 nor rfc2918 defines an OPEN optional parameter. Neither rfc2858 nor rfc2918 defines an OPEN optional parameter.
With this in mind I would suggest to add the following text: With this in mind I would suggest to add the following text:
[RFC2842] defines another Optional Parameter. [RFC2842] defines another Optional Parameter.
The original poster agreed with this modification. This issue is at The original poster agreed with this modification. This issue is at
consensus. consensus.
2.32 Clarify EGP Reference 2.32. Clarify EGP Reference
Status: Consensus Status: Consensus
Change: No Change: No
Summary: The consensus is that this was addressed in 32.1, so we can Summary: The consensus is that this was addressed in 32.1, so we can
close this. close this.
Discussion: Discussion:
3. P. 13, EGP, are there other EGP protocols other than BGP that are 3. P. 13, EGP, are there other EGP protocols other than BGP that are
in use? If not, change EGP to BGP. in use? If not, change EGP to BGP.
A response to this suggested that we add a reference to [1] (the EGP A response to this suggested that we add a reference to [1] (the EGP
spec) here. spec) here.
Another response clarified that this refers to EGP-the-protocol and Another response clarified that this refers to EGP-the-protocol and
NOT the class. NOT the class.
Another response disagreed, but suggested that: Another response disagreed, but suggested that:
IGP = network was explicitly introduced into bgp (network cmd) IGP = network was explicitly introduced into bgp (network cmd)
INCOMPLETE = network was implicitly introduced into bgp INCOMPLETE = network was implicitly introduced into bgp
(redistribute) EGP = other (redistribute) EGP = other
The original commenter thought that this referred to EGP-the-class of The original commenter thought that this referred to EGP-the-class of
protocols. And why not use BGP therefore, as the only EGP. protocols. And why not use BGP therefore, as the only EGP.
There was some discussion over whether or not we should mention There was some discussion over whether or not we should mention
something that is historical. something that is historical.
Jeff suggested a footnote in the Origin section about EGP. Jeff suggested a footnote in the Origin section about EGP.
Curtis suggested that we state that the EGP in ORIGIN is deprecated, Curtis suggested that we state that the EGP in ORIGIN is deprecated,
but retain the value to document what it used to mean. but retain the value to document what it used to mean.
This reviewer thinks a statement about whether this "EGP" origin This reviewer thinks a statement about whether this "EGP" origin
skipping to change at page 37, line 50 skipping to change at page 19, line 952
Yakov replied that an EGP reference will be added (see issue 9). Yakov replied that an EGP reference will be added (see issue 9).
Yakov also stated that he doesn't see what is wrong with the current Yakov also stated that he doesn't see what is wrong with the current
text, and suggested we keep it. This includes leaving out any text, and suggested we keep it. This includes leaving out any
reference to the status of the EGP spec. He sees that it is clear reference to the status of the EGP spec. He sees that it is clear
from context that we are talking about "the EGP" [RFC904]. from context that we are talking about "the EGP" [RFC904].
Jeff noted that this issue has been sufficiently addressed in the Jeff noted that this issue has been sufficiently addressed in the
solution to 32.1. This met with agreement. We are at consensus. solution to 32.1. This met with agreement. We are at consensus.
2.32.1 EGP ORIGIN Clarification 2.32.1. EGP ORIGIN Clarification
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Change section 5.1.1 to read: Summary: Change section 5.1.1 to read:
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the associated shall be generated by the speaker that originates the associated
routing information. Its value SHOULD NOT be changed by any other routing information. Its value SHOULD NOT be changed by any other
speaker." speaker."
Consensus to change: Consensus to change:
1 EGP - Network Layer Reachability Information 1 EGP - Network Layer Reachability Information learned via the EGP
learned via the EGP protocol protocol
to: to:
1 EGP - Network Layer Reachability Information 1 EGP - Network Layer Reachability Information learned via the EGP
learned via the EGP protocol [RFC904] protocol [RFC904]
Discussion: Discussion:
This discussion is picked up again in the "Review of draft-ietf-idr- This discussion is picked up again in the "Review of
bgp4-17" thread, where specific text is proposed: draft-ietf-idr-bgp4-17" thread, where specific text is proposed:
Old: Old:
"ORIGIN is a well-known mandatory attribute that defines the "ORIGIN is a well-known mandatory attribute that defines the origin
origin of the path information. The data octet can assume of the path information. The data octet can assume the following
the following values: values:
Value Meaning Value Meaning
0 IGP - Network Layer Reachability Information 0 IGP - Network Layer Reachability Information is interior to the
is interior to the originating AS originating AS
1 EGP - Network Layer Reachability Information 1 EGP - Network Layer Reachability Information learned via the EGP
learned via the EGP protocol protocol
2 INCOMPLETE - Network Layer Reachability 2 INCOMPLETE - Network Layer Reachability Information learned by some
Information learned by some other means" New: other means" New:
"ORIGIN is a well-known mandatory attribute that defines the "ORIGIN is a well-known mandatory attribute that defines the origin
origin of the path information. The data octet can assume of the path information. The data octet can assume the following
the following values: values:
Value Meaning Value Meaning
0 IGP - NLRI was explicitly introduced into bgp
1 EGP - this value was administratively 0 IGP - NLRI was explicitly introduced into bgp
configured to affect policy decisions or NLRI was
learned via the EGP protocol [1]
2 INCOMPLETE - NLRI was implicitly introduced 1 EGP - this value was administratively configured to affect policy
into bgp" decisions or NLRI was learned via the EGP protocol [1]
2 INCOMPLETE - NLRI was implicitly introduced into bgp"
since: 1) The network command sets the origin to IGP and I remember since: 1) The network command sets the origin to IGP and I remember
seeing somewhere that only static routes should be set to IGP. 2) seeing somewhere that only static routes should be set to IGP. 2) The
The primary use of EGP value is policy 3) EGP seems to still exist, primary use of EGP value is policy 3) EGP seems to still exist,
anyway even if it does not it is not worth re-writing the world. anyway even if it does not it is not worth re-writing the world.
Also, change: "5.1.1 ORIGIN Also, change: "5.1.1 ORIGIN
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the autonomous system that originates the shall be generated by the autonomous system that originates the
associated routing information. It shall be included in the UPDATE associated routing information. It shall be included in the UPDATE
messages of all BGP speakers that choose to propagate this messages of all BGP speakers that choose to propagate this
information to other BGP speakers." information to other BGP speakers."
to: "5.1.1 ORIGIN to: "5.1.1 ORIGIN
The value of the ORIGIN attribute shall be set by the speaker that The value of the ORIGIN attribute shall be set by the speaker that
originates the associated NLRI. Its value shall not be changed originates the associated NLRI. Its value shall not be changed by
by any other speaker unless the other speaker is administratively any other speaker unless the other speaker is administratively
configured to do so to affect policy decisions." configured to do so to affect policy decisions."
since: 1) It is already defined as well-known mandatory attribute. since: 1) It is already defined as well-known mandatory attribute. 2)
2) It may be set differently within the same AS (not saying this is It may be set differently within the same AS (not saying this is
good). 3) It is commonly used for policy, but by default does not good). 3) It is commonly used for policy, but by default does not get
get changed. 4) Speakers have no choice, it is mandatory. changed. 4) Speakers have no choice, it is mandatory.
After much continued discussion on this in the "issue 32.1" thread, After much continued discussion on this in the "issue 32.1" thread,
we seem to have come to a consensus that section 5.1.1 should read: we seem to have come to a consensus that section 5.1.1 should read:
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the associated shall be generated by the speaker that originates the associated
routing information. Its value should not be changed by any other routing information. Its value should not be changed by any other
speaker unless the other speaker is administratively configured to do speaker unless the other speaker is administratively configured to do
so to affect policy decisions." so to affect policy decisions."
This text met with a number of agreements, and one disagreement This text met with a number of agreements, and one disagreement
stating that we shouldn't have the "unless administratively stating that we shouldn't have the "unless administratively
configured" portion. configured" portion.
After some further discussion, we have this text on the table: After some further discussion, we have this text on the table:
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is
generated by the BGP speaker that originates the associated BGP generated by the BGP speaker that originates the associated BGP
routing information. The attribute shall be included in the UPDATE routing information. The attribute shall be included in the UPDATE
messages of all BGP speakers that choose to propagate this messages of all BGP speakers that choose to propagate this
information to other BGP speakers. information to other BGP speakers.
Jonathan suggested that we change "propagate this information" to Jonathan suggested that we change "propagate this information" to
"forward this route". He also mentioned that he would prefer "forward this route". He also mentioned that he would prefer
something more explicit instead of/in addition to "The attribute something more explicit instead of/in addition to "The attribute
shall be included in the UPDATE messages of all BGP speakers that shall be included in the UPDATE messages of all BGP speakers that
choose to propagate this information to other BGP speakers." such as choose to propagate this information to other BGP speakers." such as
"other speakers do not change the ORIGIN value." "other speakers do not change the ORIGIN value."
On the issue of making the EGP ORIGIN type more clear Andrew On the issue of making the EGP ORIGIN type more clear Andrew
proposed: proposed:
To me, there seems to be sufficient confusion around the "EGP" To me, there seems to be sufficient confusion around the "EGP"
reference to merit some sort of clarification. The simplest reference to merit some sort of clarification. The simplest
modification would be to change: modification would be to change:
1 EGP - Network Layer Reachability Information 1 EGP - Network Layer Reachability Information learned via the EGP
learned via the EGP protocol protocol
to: to:
1 EGP - Network Layer Reachability Information 1 EGP - Network Layer Reachability Information learned via the EGP
learned via the EGP protocol [RFC904] protocol [RFC904]
That would clarify that we're talking about the protocol, and not the That would clarify that we're talking about the protocol, and not the
class-of-protocols, or EBGP. It would leave unstated that this could class-of-protocols, or EBGP. It would leave unstated that this could
theoretically be used to muck with route selection. I think that is theoretically be used to muck with route selection. I think that is
ok. If operators want to override ORIGIN to affect some hoho magic, ok. If operators want to override ORIGIN to affect some hoho magic,
they are welcome to do so, but I don't think it needs to be they are welcome to do so, but I don't think it needs to be
documented in the base spec. documented in the base spec.
This met with a number of agreements. This met with a number of agreements.
On the second text section we are working on, Jonathan objected to On the second text section we are working on, Jonathan objected to
the current working text below and suggested an alternate: the current working text below and suggested an alternate:
CHANGE: CHANGE:
"ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is
generated by the BGP speaker that originates the associated BGP generated by the BGP speaker that originates the associated BGP
routing information. The attribute shall be included in the UPDATE routing information. The attribute shall be included in the UPDATE
messages of all BGP speakers that choose to propagate this messages of all BGP speakers that choose to propagate this
information to other BGP speakers." information to other BGP speakers."
TO: TO:
"ORIGIN is a well-known mandatory attribute. The ORIGIN attribute "ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the associated shall be generated by the speaker that originates the associated
routing information. Its value should not be changed by any other routing information. Its value should not be changed by any other
speaker unless the other speaker is administratively configured to do speaker unless the other speaker is administratively configured to do
so to affect policy decisions." so to affect policy decisions."
-or- -or-
"ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
"ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the associated shall be generated by the speaker that originates the associated
routing information. Its value should not be changed by any other routing information. Its value should not be changed by any other
speaker." speaker."
Jonathan cited a recent example of someone who was still confused by Jonathan cited a recent example of someone who was still confused by
this section of the text in -17 (not specifically the working text). this section of the text in -17 (not specifically the working text).
Yakov proposed this as final text: Yakov proposed this as final text:
In 4.3: In 4.3:
a) ORIGIN (Type Code 1): a) ORIGIN (Type Code 1):
ORIGIN is a well-known mandatory attribute that defines the origin of ORIGIN is a well-known mandatory attribute that defines the origin of
the path information. The data octet can assume the following the path information. The data octet can assume the following
values: values:
Value Meaning Value Meaning
0 IGP - Network Layer Reachability Information 0 IGP - Network Layer Reachability Information is interior to the
is interior to the originating AS originating AS
1 EGP - Network Layer Reachability Information 1 EGP - Network Layer Reachability Information learned via the EGP
learned via the EGP protocol [RFC904] protocol [RFC904]
2 INCOMPLETE - Network Layer Reachability 2 INCOMPLETE - Network Layer Reachability Information learned by some
Information learned by some other means other means
Usage of this attribute is defined in 5.1.1. Usage of this attribute is defined in 5.1.1.
In 5.1.1: In 5.1.1:
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the associated shall be generated by the speaker that originates the associated
routing information. Its value SHOULD NOT be changed by any other routing information. Its value SHOULD NOT be changed by any other
speaker." speaker."
This met with agreement. This issue is at consensus. This met with agreement. This issue is at consensus.
2.32.2 BGP Destination-based Forwarding Paradigm 2.32.2. BGP Destination-based Forwarding Paradigm
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: After much discussion, this is the consensus: This text in Summary: After much discussion, this is the consensus: This text in
the current draft: the current draft:
To characterize the set of policy decisions that can be enforced To characterize the set of policy decisions that can be enforced
using BGP, one must focus on the rule that a BGP speaker advertises using BGP, one must focus on the rule that a BGP speaker advertises
to its peers (other BGP speakers which it communicates with) in to its peers (other BGP speakers which it communicates with) in
neighboring ASs only those routes that it itself uses. This rule neighboring ASs only those routes that it itself uses. This rule
reflects the "hop-by-hop" routing paradigm generally used throughout reflects the "hop-by-hop" routing paradigm generally used throughout
the current Internet. Note that some policies cannot be supported by the current Internet. Note that some policies cannot be supported by
the "hop-by-hop" routing paradigm and thus require techniques such as the "hop-by-hop" routing paradigm and thus require techniques such as
source routing (aka explicit routing) to enforce. For example, BGP source routing (aka explicit routing) to enforce. For example, BGP
does not enable one AS to send traffic to a neighboring AS intending does not enable one AS to send traffic to a neighboring AS intending
that the traffic take a different route from that taken by traffic that the traffic take a different route from that taken by traffic
originating in the neighboring AS. On the other hand, BGP can support originating in the neighboring AS. On the other hand, BGP can
any policy conforming to the "hop-by-hop" routing paradigm. Since the support any policy conforming to the "hop-by-hop" routing paradigm.
current Internet uses only the "hop-by-hop" inter-AS routing paradigm Since the current Internet uses only the "hop-by-hop" inter-AS
and since BGP can support any policy that conforms to that paradigm, routing paradigm and since BGP can support any policy that conforms
BGP is highly applicable as an inter-AS routing protocol for the to that paradigm, BGP is highly applicable as an inter-AS routing
current Internet. protocol for the current Internet.
will be replaced in -18 with the following text: will be replaced in -18 with the following text:
Routing information exchanged via BGP supports only the destination- Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy header of the packet. This, in turn, reflects the set of policy
decisions that can (and can not) be enforced using BGP. Note that decisions that can (and can not) be enforced using BGP. Note that
some policies cannot be supported by the destination-based forwarding some policies cannot be supported by the destination-based forwarding
paradigm, and thus require techniques such as source routing (aka paradigm, and thus require techniques such as source routing (aka
explicit routing) to be enforced*. Such policies can not be enforced explicit routing) to be enforced*. Such policies can not be enforced
using BGP either. For example, BGP does not enable one AS to send using BGP either. For example, BGP does not enable one AS to send
traffic to a neighboring AS for forwarding to some destination traffic to a neighboring AS for forwarding to some destination
(reachable through but) beyond that neighboring AS intending that the (reachable through but) beyond that neighboring AS intending that the
traffic take a different route to that taken by the traffic traffic take a different route to that taken by the traffic
originating in the neighboring AS (for that same destination). On originating in the neighboring AS (for that same destination). On
the other hand, BGP can support any policy conforming to the the other hand, BGP can support any policy conforming to the
destination-based forwarding paradigm. destination-based forwarding paradigm.
Discussion: Discussion:
In response to these proposals, Yakov proposed that the real problem In response to these proposals, Yakov proposed that the real problem
is that it is not clear that BGP is build to support the destination- is that it is not clear that BGP is build to support the destination-
based forwarding paradigm. To fix this, it was proposed that: based forwarding paradigm. To fix this, it was proposed that:
<OLD> <OLD>
To characterize the set of policy decisions that can be enforced To characterize the set of policy decisions that can be enforced
using BGP, one must focus on the rule that a BGP speaker advertises using BGP, one must focus on the rule that a BGP speaker advertises
to its peers (other BGP speakers which it communicates with) in to its peers (other BGP speakers which it communicates with) in
neighboring ASs only those routes that it itself uses. This rule neighboring ASs only those routes that it itself uses. This rule
reflects the "hop-by-hop" routing paradigm generally used throughout reflects the "hop-by-hop" routing paradigm generally used throughout
the current Internet. Note that some policies cannot be supported by the current Internet. Note that some policies cannot be supported by
the "hop-by-hop" routing paradigm and thus require techniques such as the "hop-by-hop" routing paradigm and thus require techniques such as
source routing (aka explicit routing) to enforce. For example, BGP source routing (aka explicit routing) to enforce. For example, BGP
does not enable one AS to send traffic to a neighboring AS intending does not enable one AS to send traffic to a neighboring AS intending
that the traffic take a different route from that taken by traffic that the traffic take a different route from that taken by traffic
originating in the neighboring AS. On the other hand, BGP can support originating in the neighboring AS. On the other hand, BGP can
any policy conforming to the "hop-by-hop" routing paradigm. Since the support any policy conforming to the "hop-by-hop" routing paradigm.
current Internet uses only the "hop-by-hop" inter-AS routing paradigm Since the current Internet uses only the "hop-by-hop" inter-AS
and since BGP can support any policy that conforms to that paradigm, routing paradigm and since BGP can support any policy that conforms
BGP is highly applicable as an inter-AS routing protocol for the to that paradigm, BGP is highly applicable as an inter-AS routing
current Internet. protocol for the current Internet.
<NEW> <NEW>
Routing information exchanged via BGP supports only the destination- Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP packet based solely on the destination address carried in the IP
header of the packet. This, in turn reflects the set of policy header of the packet. This, in turn reflects the set of policy
decisions that can (and can not) be enforced using BGP. Note that decisions that can (and can not) be enforced using BGP. Note that
some policies cannot be supported by the destination-based forwarding some policies cannot be supported by the destination-based forwarding
paradigm and thus require techniques such as source routing (aka paradigm and thus require techniques such as source routing (aka
explicit routing) to enforce. Such policies can not be enforced using explicit routing) to enforce. Such policies can not be enforced
BGP either. For example, BGP does not enable one AS to send traffic using BGP either. For example, BGP does not enable one AS to send
to a neighboring AS intending that the traffic take a different route traffic to a neighboring AS intending that the traffic take a
from that taken by traffic originating in the neighboring AS. On different route from that taken by traffic originating in the
the other hand, BGP can support any policy conforming to the neighboring AS. On the other hand, BGP can support any policy
destination-based forwarding paradigm. conforming to the destination-based forwarding paradigm.
Curtis thinks the newer text here is more clear. Curtis thinks the newer text here is more clear.
In response to the new text, Christian Martin proposed a slightly In response to the new text, Christian Martin proposed a slightly
different new text: different new text:
Routing information exchanged via BGP supports only the destination- Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP packet based solely on the destination address carried in the IP
header of the packet. This, in turn reflects the set of policy header of the packet. This, in turn reflects the set of policy
decisions that can (and can not) be enforces using BGP. Note that decisions that can (and can not) be enforces using BGP. Note that
some policies cannot be supported by the destination-based forwarding some policies cannot be supported by the destination-based forwarding
paradigm and thus require techniques such as source routing (aka paradigm and thus require techniques such as source routing (aka
explicit routing) to enforce. Such policies can not be enforced using explicit routing) to enforce. Such policies can not be enforced
BGP either. For example, BGP does not enable one AS to send traffic using BGP either. For example, BGP does not enable one AS to send
to a neighboring AS based on prefixes originating from the local AS. traffic to a neighboring AS based on prefixes originating from the
On the other hand, BGP can support any policy conforming to the local AS. On the other hand, BGP can support any policy conforming
destination-based forwarding paradigm. to the destination-based forwarding paradigm.
To which Yakov replied: To which Yakov replied:
Routing information exchanged via BGP supports only the destination- Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy header of the packet. This, in turn, reflects the set of policy
decisions that can (and can not) be enforces using BGP. Note that decisions that can (and can not) be enforces using BGP. Note that
some policies cannot be supported by the destination-based forwarding some policies cannot be supported by the destination-based forwarding
paradigm, and thus require techniques such as source routing (aka paradigm, and thus require techniques such as source routing (aka
explicit routing) to enforce. Such policies can not be enforced using explicit routing) to enforce. Such policies can not be enforced
BGP either. For example, BGP does not enable one AS to send traffic using BGP either. For example, BGP does not enable one AS to send
through a neighboring AS to some destination (which is outside of the traffic through a neighboring AS to some destination (which is
neighboring AS, but is reachable through the neighboring AS) outside of the neighboring AS, but is reachable through the
intending that the traffic take a different route from that taken by neighboring AS) intending that the traffic take a different route
the traffic to the same destination that originating in the from that taken by the traffic to the same destination that
neighboring AS. On the other hand, BGP can support any policy originating in the neighboring AS. On the other hand, BGP can
conforming to the destination-based forwarding paradigm. support any policy conforming to the destination-based forwarding
paradigm.
And Chris responded: And Chris responded:
Routing information exchanged via BGP supports only the destination- Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy header of the packet. This, in turn, reflects the set of policy
decisions that can (and can not) be enforces using BGP. Note that decisions that can (and can not) be enforces using BGP. Note that
some policies cannot be supported by the destination-based forwarding some policies cannot be supported by the destination-based forwarding
paradigm, and thus require techniques such as source routing (aka paradigm, and thus require techniques such as source routing (aka
explicit routing) to enforce. Such policies can not be enforced using explicit routing) to enforce. Such policies can not be enforced
BGP either. For example, BGP does not enable one AS to send traffic using BGP either. For example, BGP does not enable one AS to send
through a neighboring AS to some destination beyond the neighboring traffic through a neighboring AS to some destination beyond the
AS intending that the traffic take a different route from that taken neighboring AS intending that the traffic take a different route from
by traffic to the same destination which originates in the that taken by traffic to the same destination which originates in the
neighboring AS. In other words, the BGP policy of a local AS cannot neighboring AS. In other words, the BGP policy of a local AS cannot
affect the downstream (aka, away from the local AS) forwarding policy affect the downstream (aka, away from the local AS) forwarding policy
of a remote AS. On the other hand, BGP can support any policy of a remote AS. On the other hand, BGP can support any policy
conforming to the destination-based forwarding paradigm. conforming to the destination-based forwarding paradigm.
Tom Petch preferred Yakov's second formulation, with these changes: Tom Petch preferred Yakov's second formulation, with these changes:
policies can not be enforced using BGP either. For example, BGP does policies can not be enforced using BGP either. For example, BGP does
not enable one AS to send traffic ! to a neighboring AS for not enable one AS to send traffic ! to a neighboring AS for
forwarding to some destination (reachable through but) beyond ! forwarding to some destination (reachable through but) beyond ! that
that neighboring AS intending that ! the traffic take a different neighboring AS intending that ! the traffic take a different route to
route to that taken by the traffic ! originating in the that taken by the traffic ! originating in the neighboring AS (for
neighboring AS (for that same destination). that same destination).
On the other hand, BGP can support any policy conforming to the On the other hand, BGP can support any policy conforming to the
destination-based forwarding paradigm. destination-based forwarding paradigm.
Yakov agreed to Tom's suggested changes. Yakov agreed to Tom's suggested changes.
2.33 Add "Optional Non-Transitive" to the MED Section 2.33. Add "Optional Non-Transitive" to the MED Section
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add "Optional Non-Transitive" to MED Section Summary: Add "Optional Non-Transitive" to MED Section Add "well-known
Add "well-known mandatory" to the NEXT_HOP Section mandatory" to the NEXT_HOP Section
Discussion: Discussion:
4. P.23, change the following: 4. P.23, change the following:
"The MULTI_EXIT_DISC attribute may be used on external (inter-AS) "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
links to discriminate among multiple exit or entry points to the same links to discriminate among multiple exit or entry points to the same
neighboring AS ..." neighboring AS ..."
To the following: To the following:
"The MULTI_EXIT_DISC is an optional non-transitive attribute which "The MULTI_EXIT_DISC is an optional non-transitive attribute which
may be used on external (inter-AS) links to discriminate among may be used on external (inter-AS) links to discriminate among
multiple exit or entry points to the same neighboring AS ..." multiple exit or entry points to the same neighboring AS ..."
skipping to change at page 45, line 50 skipping to change at page 19, line 1331
obvious to him. obvious to him.
Yakov agreed to make this change in -18. Yakov agreed to make this change in -18.
Jonathan replied that: Jonathan replied that:
5.1.3 NEXT_HOP also, it is missing " well-known mandatory". 5.1.3 NEXT_HOP also, it is missing " well-known mandatory".
Yakov also agreed to make this change. Yakov also agreed to make this change.
2.34 Timer & Counter Definition 2.34. Timer & Counter Definition
Status: Consensus Status: Consensus
Change: No Change: No
Summary: No discussion, no text proposed, defaults to consensus for Summary: No discussion, no text proposed, defaults to consensus for
no change. no change.
Discussion: Discussion:
5. In section 8, there are a number of Timers, Counters, etc. that 5. In section 8, there are a number of Timers, Counters, etc. that
need to be explicitly defined before they are used by the FSM. need to be explicitly defined before they are used by the FSM.
Perhaps these definitions should go in the Glossary section. Perhaps these definitions should go in the Glossary section.
There has been no further discussion on this issue. Unless it is There has been no further discussion on this issue. Unless it is
brought up again, this issue is in consensus, with no change. brought up again, this issue is in consensus, with no change.
2.35 Fix Typo 2.35. Fix Typo
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Fix a Typo. No discussion, but this seem clear. Summary: Fix a Typo. No discussion, but this seem clear.
Discussion: Discussion:
1. P. 41. Typing error, "Each time time the local system...". 1. P. 41. Typing error, "Each time time the local system...".
2.36 Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary 2.36. Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: This change requires a glossary. Yakov has committed to Summary: This change requires a glossary. Yakov has committed to
having a section where commonly used terms are defined in draft 18, having a section where commonly used terms are defined in draft 18,
so this issue is at consensus. so this issue is at consensus.
Discussion: Discussion:
2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in 2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in
the glossary, so when they are used in section 9.1, it is well the glossary, so when they are used in section 9.1, it is well
understood what they are. understood what they are.
Yakov replied: Yakov replied:
will be added to the section "Definition of commonly used terms" in will be added to the section "Definition of commonly used terms" in
-18 version. -18 version.
2.37 Combine "Unfeasible Routes" and "Withdrawn Routes" 2.37. Combine "Unfeasible Routes" and "Withdrawn Routes"
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add the following terms to the "commonly used terms Summary: Add the following terms to the "commonly used terms
section": section":
Feasible route A route that is available for use. Feasible route A route that is available for use.
Unfeasible route A previously advertised feasible route that is no Unfeasible route A previously advertised feasible route that is no
longer available for use. longer available for use.
Discussion: Discussion:
3. P. 45, Phase I, There is no definition of what are unfeasible 3. P. 45, Phase I, There is no definition of what are unfeasible
routes? Are they the same as withdrawn routes? If so, the two should routes? Are they the same as withdrawn routes? If so, the two
be combined to one name. should be combined to one name.
Ishi replied to this that he thought that we could combine the two Ishi replied to this that he thought that we could combine the two
terms, since there is limited difference from an implementation terms, since there is limited difference from an implementation
standpoint. standpoint.
Yakov replied: Yakov replied:
The routes are withdrawn from service because they are unfeasible, The routes are withdrawn from service because they are unfeasible,
not because they are "withdrawn". So, we need to keep the term not because they are "withdrawn". So, we need to keep the term
"unfeasible" to indicate the *reason* why a route could be withdrawn. "unfeasible" to indicate the *reason* why a route could be withdrawn.
On the other hand, "withdrawn" is used as a verb, and to the best of On the other hand, "withdrawn" is used as a verb, and to the best of
my knowledge "unfeasible" can't be used as a verb. With this in my knowledge "unfeasible" can't be used as a verb. With this in
mind, I don't think that we can combine the two into a single term. mind, I don't think that we can combine the two into a single term.
Ishi replied that he was convinced, and that the terms should stay Ishi replied that he was convinced, and that the terms should stay
separate. separate.
Andrew asked the list if we should define these terms in the Andrew asked the list if we should define these terms in the
"commonly used terms" section in draft -18. "commonly used terms" section in draft -18.
skipping to change at page 47, line 52 skipping to change at page 19, line 1430
terms, and found: terms, and found:
It turns out there there is an inconsistency in the usage of the word It turns out there there is an inconsistency in the usage of the word
withdrawn. withdrawn.
Section 3.1: Section 3.1:
There are three methods by which a given BGP speaker can indicate There are three methods by which a given BGP speaker can indicate
that a route has been withdrawn from service: that a route has been withdrawn from service:
... ...
b) a replacement route with the same NLRI can be advertised, or b) a replacement route with the same NLRI can be advertised, or
... ...
Later, in the definition of Withdrawn Routes Length, we have: Later, in the definition of Withdrawn Routes Length, we have:
A value of 0 indicates that no routes are being withdrawn from A value of 0 indicates that no routes are being withdrawn from
service, service,
Taken together, this could be construed as meaning that a Withdrawn Taken together, this could be construed as meaning that a Withdrawn
Routes Length of 0 indicates that all routes included in the UPDATE Routes Length of 0 indicates that all routes included in the UPDATE
represent newly feasible routes... not replacement routes. represent newly feasible routes... not replacement routes.
skipping to change at page 48, line 45 skipping to change at page 19, line 1472
There are three methods by which a given BGP speaker can indicate There are three methods by which a given BGP speaker can indicate
that a route has been removed from service: that a route has been removed from service:
or: or:
There are three methods by which a given BGP speaker can indicate There are three methods by which a given BGP speaker can indicate
that a route is now unfeasible: that a route is now unfeasible:
After some further off-list discussion, mrr agreed that this After some further off-list discussion, mrr agreed that this
inconsistency is extremely minor, and withdrew his comment. feasible inconsistency is extremely minor, and withdrew his comment. feasible
and unfeasible route will be defined in the "commonly used terms" and unfeasible route will be defined in the "commonly used terms"
section to clear up any confusion. section to clear up any confusion.
2.38 Clarify Outbound Route Text 2.38. Clarify Outbound Route Text
Status: Consensus Status: Consensus
Change: No Change: No
Summary: Consensus that the issue was sufficiently minor to leave Summary: Consensus that the issue was sufficiently minor to leave
things alone. things alone.
Discussion: Discussion:
4. P. 50, line, "If a route in Loc-RIB is excluded from a particular 4. P. 50, line, "If a route in Loc-RIB is excluded from a particular
Adj-RIB-Out the previously advertised route in that Adj-RIB-Out must Adj-RIB-Out the previously advertised route in that Adj-RIB-Out must
be withdrawn from service by means of an UPDATE message (see 9.2)." be withdrawn from service by means of an UPDATE message (see 9.2)."
Would like to rephrase the sentence for clarity, "If a route in Loc- Would like to rephrase the sentence for clarity, "If a route in Loc-
RIB is excluded from a particular Adj-RIB-Out and was previously RIB is excluded from a particular Adj-RIB-Out and was previously
advertised via Adj-RIB-Out, it must be withdrawn from service by advertised via Adj-RIB-Out, it must be withdrawn from service by
means of an UPDATE message (see 9.2)." means of an UPDATE message (see 9.2)."
One comment suggested either leave it alone, or remove "via Adj-RIB- One comment suggested either leave it alone, or remove "via Adj-RIB-
Out". Out".
The original commenter withdrew the comment. The original commenter withdrew the comment.
2.39 Redundant Sentence Fragments 2.39. Redundant Sentence Fragments
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Fix typo & parentheses. Summary: Fix typo & parentheses.
Discussion: Discussion:
5. P. 50, section 9.1.4, The two fragments of this sentence are 5. P. 50, section 9.1.4, The two fragments of this sentence are
redundant and don't say anything new or simplify the content. Just redundant and don't say anything new or simplify the content. Just
keep one fragment. keep one fragment.
"A route describing a smaller set of destinations (a longer prefix) "A route describing a smaller set of destinations (a longer prefix)
is said to be more specific than a route describing a larger set of is said to be more specific than a route describing a larger set of
destinations (a shorted prefix); similarly, a route describing a destinations (a shorted prefix); similarly, a route describing a
larger set of destinations (a shorter prefix) is said to be less larger set of destinations (a shorter prefix) is said to be less
specific than a route describing a smaller set of destinations (a specific than a route describing a smaller set of destinations (a
longer prefix)." longer prefix)."
There was a comment that disagreed, thinking that both "more There was a comment that disagreed, thinking that both "more
skipping to change at page 50, line 12 skipping to change at page 19, line 1536
Jonathan replied to this: Jonathan replied to this:
Disagree, the text if fine the way it is, except you need to change Disagree, the text if fine the way it is, except you need to change
"shorted" to "shorter". "shorted" to "shorter".
After minimal further discussion, it was decided we are at a After minimal further discussion, it was decided we are at a
consensus on this issue to fix the typo and drop the third and fourth consensus on this issue to fix the typo and drop the third and fourth
parentheses. parentheses.
2.40 Section 9.2.1.1 - Per Peer vs. Per Router 2.40. Section 9.2.1.1 - Per Peer vs. Per Router
MinRouteAdvertisementInterval MinRouteAdvertisementInterval
Status: Consensus Status: Consensus
Change: No Change: No
Summary: The consensus is that current practice allows for the Summary: The consensus is that current practice allows for the
MinRouteAdvertisementInterval to be set per peer, so the text should MinRouteAdvertisementInterval to be set per peer, so the text should
be kept the same. be kept the same.
Discussion: Discussion:
6. P. 52, section 9.2.1.1 Change this sentence for clarity, "This 6. P. 52, section 9.2.1.1 Change this sentence for clarity, "This
rate limiting procedure applies on a per-destination basis, although rate limiting procedure applies on a per-destination basis, although
the value of MinRouteAdvertisementInterval is set on a per BGP peer the value of MinRouteAdvertisementInterval is set on a per BGP peer
basis." basis."
To This: "This rate limiting procedure applies on a per-destination To This: "This rate limiting procedure applies on a per-destination
basis, although the value of MinRouteAdvertisementInterval is set on basis, although the value of MinRouteAdvertisementInterval is set on
a BGP router (same value for all peers) basis." a BGP router (same value for all peers) basis."
There was a comment disagreeing with this proposal. It was later There was a comment disagreeing with this proposal. It was later
elaborated on to include that the reason for disagreement was that elaborated on to include that the reason for disagreement was that
skipping to change at page 50, line 47 skipping to change at page 19, line 1571
deeper that needs to be clarified? Again, response to this is that deeper that needs to be clarified? Again, response to this is that
current implementations allow the MinRouteAdvertisementInterval to be current implementations allow the MinRouteAdvertisementInterval to be
set per-peer, not per-router. set per-peer, not per-router.
Original reviewer conceded the point. Original reviewer conceded the point.
There was some additional discussion on this point. Most of it was There was some additional discussion on this point. Most of it was
along the lines of extracting what was really implemented and along the lines of extracting what was really implemented and
supported among various vendors. The conclusion was the same. supported among various vendors. The conclusion was the same.
2.41 Mention FSM Internal Timers 2.41. Mention FSM Internal Timers
Status: Consensus Status: Consensus
Change: No Change: No
Summary: No discussion on this issue. No text proposed. Perhaps Summary: No discussion on this issue. No text proposed. Perhaps
this is in the FSM section of the draft? Either way, it defaults to this is in the FSM section of the draft? Either way, it defaults to
consensus with no change. consensus with no change.
Discussion: Discussion:
7. P. 61, item 6.4. Although all the BGP protocol interfacing timers 7. P. 61, item 6.4. Although all the BGP protocol interfacing
are mentioned, there are a few FSM internal timers mentioned in the timers are mentioned, there are a few FSM internal timers mentioned
spec that need to be covered here as well. in the spec that need to be covered here as well.
There has been no discussion on this, it now defaults to consensus There has been no discussion on this, it now defaults to consensus
with no change. with no change.
2.42 Delete the FSM Section 2.42. Delete the FSM Section
Status: Consensus Status: Consensus
Change: No Change: No
Summary: There was some confusion on the question: Is the FSM draft Summary: There was some confusion on the question: Is the FSM draft
going to be a separate document, or incorporated into the base draft. going to be a separate document, or incorporated into the base draft.
The consensus is that it is going to become part of the base draft, The consensus is that it is going to become part of the base draft,
so the FSM section will be kept, and elaborated on. so the FSM section will be kept, and elaborated on.
Discussion: Discussion:
8. Since there is going to be an FSM spec, do we need to have FSM 8. Since there is going to be an FSM spec, do we need to have FSM
descriptions in this spec. Maybe the FSM section should be delete. descriptions in this spec. Maybe the FSM section should be delete.
There was one response agreeing with this. One response asking for There was one response agreeing with this. One response asking for
clarification: Was this a move to remove section 8. Finite State clarification: Was this a move to remove section 8. Finite State
Machine from the base draft?? The original reviewer said, yes, when Machine from the base draft?? The original reviewer said, yes, when
Sue's FSM draft becomes a WG document, we should remove section 8 Sue's FSM draft becomes a WG document, we should remove section 8
from the base draft. Yakov asked that the AD's provide input on this from the base draft. Yakov asked that the AD's provide input on this
suggestion. suggestion.
Alex responded saying that the FSM draft is going to be part of the Alex responded saying that the FSM draft is going to be part of the
base spec, and not another document once the FSM words are approved. base spec, and not another document once the FSM words are approved.
2.43 Clarify the NOTIFICATION Section 2.43. Clarify the NOTIFICATION Section
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Replace: Summary: Replace:
"If a peer sends a NOTIFICATION message, and there is an error in "If a peer sends a NOTIFICATION message, and there is an error in
that message, there is unfortunately no means of reporting this error that message, there is unfortunately no means of reporting this error
via a subsequent NOTIFICATION message." via a subsequent NOTIFICATION message."
With: With:
skipping to change at page 52, line 25 skipping to change at page 19, line 1646
To: "If a peer receives a NOTIFICATION message, and there is an error To: "If a peer receives a NOTIFICATION message, and there is an error
in that message, there is unfortunately no means of reporting this in that message, there is unfortunately no means of reporting this
error via a subsequent NOTIFICATION message." error via a subsequent NOTIFICATION message."
This reversal of meaning met with disagreement, and this text was This reversal of meaning met with disagreement, and this text was
proposed instead: proposed instead:
All errors detected while processing the NOTIFICATION message cannot All errors detected while processing the NOTIFICATION message cannot
be indicated by sending subsequent NOTIFICATION message back to be indicated by sending subsequent NOTIFICATION message back to
originating peer, therefore there is no means of reporting originating peer, therefore there is no means of reporting
NOTIFICATION message processing errors. Any error, such as an NOTIFICATION message processing errors. Any error, such as an
unrecognized Error Code or Error Subcode, should be noticed, logged unrecognized Error Code or Error Subcode, should be noticed, logged
locally, and brought to the attention of the administration of the locally, and brought to the attention of the administration of the
peer that has sent the message. The means to do this, however, lies peer that has sent the message. The means to do this, however, lies
outside the scope of this document. outside the scope of this document.
The original posted agreed with the intent of the respondent's text, The original posted agreed with the intent of the respondent's text,
thought it was too wordy, but did not propose alternate text. thought it was too wordy, but did not propose alternate text.
Yakov replied with this proposed text: Yakov replied with this proposed text:
If a peer sends a NOTIFICATION message, and the receiver of the If a peer sends a NOTIFICATION message, and the receiver of the
message detects an error in that message, the receiver can not use a message detects an error in that message, the receiver can not use a
NOTIFICATION message to report this error back to the peer. NOTIFICATION message to report this error back to the peer.
Two responses liked this new text. Unless there are objections, Two responses liked this new text. Unless there are objections,
we'll consider that a consensus. we'll consider that a consensus.
2.44 Section 6.2: OPEN message error handling 2.44. Section 6.2: OPEN message error handling
Status: Consensus Status: Consensus
Change: No Change: No
Summary: One commenter observed that the spec seems to specify Summary: One commenter observed that the spec seems to specify
behavior that doesn't seem to be observed by extant implementations, behavior that doesn't seem to be observed by extant implementations,
and suggested modifications to the spec. They were later reminded and suggested modifications to the spec. They were later reminded
that the base behavior is acceptable, and agreed. that the base behavior is acceptable, and agreed.
Discussion: Discussion:
skipping to change at page 53, line 13 skipping to change at page 19, line 1681
that the base behavior is acceptable, and agreed. that the base behavior is acceptable, and agreed.
Discussion: Discussion:
The "BGP4 draft ; section 6.2" thread began with a discussion of The "BGP4 draft ; section 6.2" thread began with a discussion of
section 6.2: OPEN message error handling. Specifically: section 6.2: OPEN message error handling. Specifically:
"If one of the optional parameters in the Open message is not "If one of the optional parameters in the Open message is not
recognized, then the error subcode is set to 'unsupported optional recognized, then the error subcode is set to 'unsupported optional
parameters" parameters"
We have hit on this line when we were testing a BGP connection We have hit on this line when we were testing a BGP connection
between a speaker that supported capability negotiation and a speaker between a speaker that supported capability negotiation and a speaker
that did not. that did not.
The speaker that did not support the negotiation closed down the The speaker that did not support the negotiation closed down the
peering session using the error clause mentioned above. Sometimes peering session using the error clause mentioned above. Sometimes
this lead to the other router to repeat the OPEN message with the this lead to the other router to repeat the OPEN message with the
Capability optional parameter; a game that went on for minutes. Capability optional parameter; a game that went on for minutes.
This router manufacturer stated in a reply to this that : "One should This router manufacturer stated in a reply to this that : "One should
not close down the connection if an optional parameter is not close down the connection if an optional parameter is
unrecognized. That would make this parameter basically mandatory. unrecognized. That would make this parameter basically mandatory.
This is an well known error in the BGP spec. Neither Cisco or Juniper This is an well known error in the BGP spec. Neither Cisco or
do this" Juniper do this"
If this is true it might be good to adapt the text. If this is true it might be good to adapt the text.
The response to this quoted RFC2842, Capabilities Advertisement with The response to this quoted RFC2842, Capabilities Advertisement with
BGP-4: BGP-4:
A BGP speaker determines that its peer doesn't support capabilities A BGP speaker determines that its peer doesn't support capabilities
advertisement, if in response to an OPEN message that carries the advertisement, if in response to an OPEN message that carries the
Capabilities Optional Parameter, the speaker receives a NOTIFICATION Capabilities Optional Parameter, the speaker receives a NOTIFICATION
message with the Error Subcode set to Unsupported Optional Parameter. message with the Error Subcode set to Unsupported Optional Parameter.
In this case the speaker should attempt to re-establish a BGP In this case the speaker should attempt to re-establish a BGP
connection with the peer without sending to the peer the Capabilities connection with the peer without sending to the peer the Capabilities
Optional Parameter. Optional Parameter.
The original poster responded: The original poster responded:
This section from the Capabilities Advertisement RFC, is indeed This section from the Capabilities Advertisement RFC, is indeed
inline with the section 6.2 of the BGP4 specification. For me however inline with the section 6.2 of the BGP4 specification. For me
the question remains if most implementations do no simply ignore however the question remains if most implementations do no simply
optional parameters that are unknown. And if so, if the text stated ignore optional parameters that are unknown. And if so, if the text
above reflects what is implemented by routers that do not have stated above reflects what is implemented by routers that do not have
capability advertisement at all. capability advertisement at all.
Yakov replied to this with: Yakov replied to this with:
RFC2842 assumes that a router (that doesn't implement RFC2842) would RFC2842 assumes that a router (that doesn't implement RFC2842) would
close the BGP session when the router receives an OPEN message with close the BGP session when the router receives an OPEN message with
an unrecognized Optional Parameter. Therefore the text in the spec an unrecognized Optional Parameter. Therefore the text in the spec
should be left unmodified. should be left unmodified.
The original poster, Jonathan, agreed with this. This issue moves to The original poster, Jonathan, agreed with this. This issue moves to
consensus. consensus.
2.45 Consistent References to BGP Peers/Connections/Sessions 2.45. Consistent References to BGP Peers/Connections/Sessions
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Stick with "BGP Connection" as the consistent term. Summary: Stick with "BGP Connection" as the consistent term.
Discussion: Discussion:
Ben proposed and Yakov responded: Ben proposed and Yakov responded:
> 1. Throughout the document we have various ways of naming the BGP > > 1. Throughout the document we have various ways of naming the BGP
peering communication. 1) BGP Session, 2) BGP Peering Session, > peering communication. 1) BGP Session, 2) BGP Peering Session,
I'll replace "session" with "connection". I'll replace "session" with "connection".
> 3) TCP Connection, > 3) TCP Connection,
The spec doesn't name BGP peering communication as "TCP connection"; The spec doesn't name BGP peering communication as "TCP connection";
TCP connection is used to establish BGP connection. So, TCP TCP connection is used to establish BGP connection. So, TCP
connection and BGP connection are two different things. connection and BGP connection are two different things.
> 4) BGP Connection, > 4) BGP Connection,
The spec is going to use this term (see above). The spec is going to use this term (see above).
> 5) BGP Peering Connection, > 5) BGP Peering Connection,
I'll replace "BGP peering connection" with "BGP connection". I'll replace "BGP peering connection" with "BGP connection".
> 6) Connection, > 6) Connection,
The text uses "connection" whenever it is clear from the context that The text uses "connection" whenever it is clear from the context that
it refers to "BGP connection" (or "TCP connection"). it refers to "BGP connection" (or "TCP connection").
> 7) BGP Speaker Connection. > 7) BGP Speaker Connection.
I'll replace "BGP Speaker Connection" with "BGP connection". I'll replace "BGP Speaker Connection" with "BGP connection".
> > BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker > > BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker
The term "speaker" is used when it is clear from the context that we The term "speaker" is used when it is clear from the context that we
are talking about "BGP speaker". are talking about "BGP speaker".
> 2. Change Internal peer to IBGP Peer. > 2. Change Internal peer to IBGP Peer.
IBGP stands for "BGP connection between internal peers". Therefore IBGP stands for "BGP connection between internal peers". Therefore
the term "IBGP Peer" would mean "BGP connection between internal the term "IBGP Peer" would mean "BGP connection between internal
peers peer". That doesn't seem appropriate. peers peer". That doesn't seem appropriate.
This issue has had some discussion, and section 3 was referenced, This issue has had some discussion, and section 3 was referenced,
specifically: specifically:
Refer to Section 3 - Summary of operations which clearly states that Refer to Section 3 - Summary of operations which clearly states that
" .. a peer in a different AS is referred to as an external peer, " .. a peer in a different AS is referred to as an external peer,
while a peer in the same AS may be described as an internal peer. while a peer in the same AS may be described as an internal peer.
Internal BGP and external BGP are commonly abbreviated IBGP and EBGP" Internal BGP and external BGP are commonly abbreviated IBGP and EBGP"
After more discussion it was decided that we should modify a After more discussion it was decided that we should modify a
paragraph on page 4 to read: paragraph on page 4 to read:
If a particular AS has multiple BGP speakers and is providing transit If a particular AS has multiple BGP speakers and is providing transit
service for other ASs, then care must be taken to ensure a consistent service for other ASs, then care must be taken to ensure a consistent
view of routing within the AS. A consistent view of the interior view of routing within the AS. A consistent view of the interior
routes of the AS is provided by the IGP used within the AS. For the routes of the AS is provided by the IGP used within the AS. For the
purpose of this document, it is assumed that a consistent view of the purpose of this document, it is assumed that a consistent view of the
routes exterior to the AS is provided by having all BGP speakers routes exterior to the AS is provided by having all BGP speakers
within the AS maintain IBGP with each other. Care must be taken to within the AS maintain IBGP with each other. Care must be taken to
ensure that the interior routers have all been updated with transit ensure that the interior routers have all been updated with transit
information before the BGP speakers announce to other ASs that information before the BGP speakers announce to other ASs that
transit service is being provided. transit service is being provided.
This change has consensus. This change has consensus.
> 3. Change External peer to EBGP Peer. > 3. Change External peer to EBGP Peer.
Ditto. Ditto.
Alex responded that having explicit definitions would be nice. This Alex responded that having explicit definitions would be nice. This
ties into the general glossary suggestion (see issues 16, 34 & 36). ties into the general glossary suggestion (see issues 16, 34 & 36).
He also suggested that: He also suggested that:
"BGP session" which works over a "TCP connection" would be closer to "BGP session" which works over a "TCP connection" would be closer to
the terminology we're actually using now and would avoid possible the terminology we're actually using now and would avoid possible
confusions when people read terms like "Connection collision") confusions when people read terms like "Connection collision")
This was discussed in the "Generial Editorial Comment" thread. This was discussed in the "Generial Editorial Comment" thread.
After some further discussion, it was decided that, due to existing After some further discussion, it was decided that, due to existing
implementations, we should go with "BGP connection" as the consistent implementations, we should go with "BGP connection" as the consistent
term. We are at consensus. term. We are at consensus.
2.46 FSM Connection Collision Detection 2.46. FSM Connection Collision Detection
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add this to section 8: Summary: Add this to section 8:
There is one FSM per connection. Prior to determining what peer a There is one FSM per connection. Prior to determining what peer a
connection is associated with there may be two connections for a connection is associated with there may be two connections for a
given peer. There should be no more than one connection per peer. given peer. There should be no more than one connection per peer.
The collision detection identifies the case where there is more than The collision detection identifies the case where there is more than
one connection per peer and provides guidance for which connection to one connection per peer and provides guidance for which connection to
skipping to change at page 57, line 20 skipping to change at page 19, line 1880
connection is known the FSM cannot be associated with a peer. The connection is known the FSM cannot be associated with a peer. The
collision is a transient condition in which the rule of "one BGP collision is a transient condition in which the rule of "one BGP
session per peer" is temporarily violated and then corrected. session per peer" is temporarily violated and then corrected.
This is discussed in the "FSM but FSM of what?" thread. This is discussed in the "FSM but FSM of what?" thread.
Sue responded that she would be happy to add Curtis' text to section Sue responded that she would be happy to add Curtis' text to section
8 and solicited any additional comments. There was only one on 8 and solicited any additional comments. There was only one on
capitalization, so this issue is at consensus. capitalization, so this issue is at consensus.
2.47 FSM - Add Explicit State Change Wording 2.47. FSM - Add Explicit State Change Wording
Status: Consensus Status: Consensus
Change: No Change: No
Summary: A desire for explicit state change wording was expressed. Summary: A desire for explicit state change wording was expressed.
No text was proposed. The assumption is that this issue has reached No text was proposed. The assumption is that this issue has reached
a happy conclusion. a happy conclusion.
Discussion: Discussion:
The initial reviewer: The initial reviewer:
skipping to change at page 57, line 46 skipping to change at page 19, line 1906
specify the new/unchanged state. Else I may be misreading it. specify the new/unchanged state. Else I may be misreading it.
There was a response asking for specific text, and offering to take There was a response asking for specific text, and offering to take
the discussion private. the discussion private.
This is discussed in the "FSM words - state changes" thread. This is discussed in the "FSM words - state changes" thread.
There has been no further discussion on this. The assumption is that There has been no further discussion on this. The assumption is that
is has reached a happy conclusion privately. is has reached a happy conclusion privately.
2.48 Explicitly Define Processing of Incoming Connections 2.48. Explicitly Define Processing of Incoming Connections
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add text that is at the end of the discussion to section 8. Summary: Add text that is at the end of the discussion to section 8.
Discussion: Discussion:
Alex suggested we explicitly define: Alex suggested we explicitly define:
- processing of incoming TCP connections (peer lookup, acceptance, - processing of incoming TCP connections (peer lookup, acceptance,
FSM creation, collision control,) FSM creation, collision control,)
Curtis later proposed this text: Curtis later proposed this text:
skipping to change at page 60, line 19 skipping to change at page 19, line 2023
given system can flip from one to the other and it does not help us given system can flip from one to the other and it does not help us
to clarify the number of FSM involved.. to clarify the number of FSM involved..
And Curtis suggested that: And Curtis suggested that:
Could this be corrected by replacing "will attempt to connect" with Could this be corrected by replacing "will attempt to connect" with
"unless configured to remain in the idle state, or configured to "unless configured to remain in the idle state, or configured to
remain passive, will attempt to connect". We could also shorten that remain passive, will attempt to connect". We could also shorten that
to "will attempt to connect unless configured otherwise". to "will attempt to connect unless configured otherwise".
Clarification (perhaps an item for a glossary entry): Clarification (perhaps an item for a glossary entry): The terms
active and passive have been in our vocabulary for almost a decade
The terms active and passive have been in our vocabulary for almost a and have proven useful. The words active and passive have slightly
decade and have proven useful. The words active and passive have different meanings applied to a TCP connection or applied to a peer.
slightly different meanings applied to a TCP connection or applied to There is only one active side and one passive side to any one TCP
a peer. There is only one active side and one passive side to any connection as per the definition below. When a BGP speaker is
one TCP connection as per the definition below. When a BGP speaker configured passive it will never attempt to connect. If a BGP
is configured passive it will never attempt to connect. If a BGP
speaker is configured active it may end up on either the active or speaker is configured active it may end up on either the active or
passive side of the connection that eventually gets established. passive side of the connection that eventually gets established.
Once the TCP connection is completed, it doesn't matter which end was Once the TCP connection is completed, it doesn't matter which end was
active and which end was passive and the only difference is which active and which end was passive and the only difference is which
side of the TCP connection has port number 179. side of the TCP connection has port number 179.
Tom agreed with Curtis, that he liked the "will attempt to connect Tom agreed with Curtis, that he liked the "will attempt to connect
unless configured otherwise" verbiage. unless configured otherwise" verbiage.
This was discussed in the "Generial Editorial Comment" thread. This was discussed in the "Generial Editorial Comment" thread.
skipping to change at page 61, line 6 skipping to change at page 19, line 2057
(text below) (text below)
8.2.2) FSM Definition 8.2.2) FSM Definition
(text now in 8.2) (text now in 8.2)
"BGP must maintain a separate FSM for each configured peer plus Each "BGP must maintain a separate FSM for each configured peer plus Each
BGP peer paired in a potential connection unless configured to remain BGP peer paired in a potential connection unless configured to remain
in the idle state, or configured to remain passive, will attempt to in the idle state, or configured to remain passive, will attempt to
to connect to the other. For the purpose of to connect to the other. For the purpose of this discussion, the
this discussion, the active or connect side of the TCP active or connect side of the TCP connection (the side of a TCP
connection (the side of a TCP connection (the side sending connection (the side sending the first TCP SYN packet) is called
the first TCP SYN packet) is called outgoing. The passive or outgoing. The passive or listening side (the sender of the first SYN
listening side (the sender of the first SYN ACK) is called ACK) is called an incoming connection. [See section on the terms
an incoming connection. [See section on the terms active and passive active and passive below.]
below.]
A BGP implementation must connect to and listen on TCP port 179 for A BGP implementation must connect to and listen on TCP port 179 for
incoming connections in addition to trying to connect to peers. Fro incoming connections in addition to trying to connect to peers. Fro
each incoming connection, a state machine must be instantiated. each incoming connection, a state machine must be instantiated.
There exists a period in which the identity of the peer on the other There exists a period in which the identity of the peer on the other
end of an incoming connection is known but the BGP identifier is not end of an incoming connection is known but the BGP identifier is not
known. During this time, both an incoming and an outgoing connection known. During this time, both an incoming and an outgoing connection
for the same configured peering may exist. This is referred to as a for the same configured peering may exist. This is referred to as a
connection collision (see Section x.x, was 6.8). connection collision (see Section x.x, was 6.8).
A BGP implementation will have at most one FSM for each configured A BGP implementation will have at most one FSM for each configured
peering plus one FSM for each incoming TCP connection for which the peering plus one FSM for each incoming TCP connection for which the
peer has not yet been identified. Each FSM corresponds to exactly one peer has not yet been identified. Each FSM corresponds to exactly
TCP connection. one TCP connection.
There may be more than one connections between a pair of peers if the There may be more than one connections between a pair of peers if the
connections are configured to use a different pair of IP addresses. connections are configured to use a different pair of IP addresses.
This is referred to as multiple "configured peerings" to the same This is referred to as multiple "configured peerings" to the same
peer. peer.
8.2.1.1) Terms "active" and "passive" 8.2.1.1) Terms "active" and "passive"
The terms active and passive have been in our vocabulary for almost a The terms active and passive have been in our vocabulary for almost a
decade and have proven useful. The words active and passive have decade and have proven useful. The words active and passive have
slightly different meanings applied to a TCP connection or applied to slightly different meanings applied to a TCP connection or applied to
a peer. There is only one active side and one passive side to any a peer. There is only one active side and one passive side to any
one TCP connection per the definition above [and the state machine one TCP connection per the definition above [and the state machine
below.] When a BGP speaker is configured active it may end up on below.] When a BGP speaker is configured active it may end up on
either the active or passive side of the connection that eventually either the active or passive side of the connection that eventually
gets established. Once the TCP connection is completed, it doesn't gets established. Once the TCP connection is completed, it doesn't
matter which end was active and which end was passive and the only matter which end was active and which end was passive and the only
difference is which side of the TCP connection has port number 179. difference is which side of the TCP connection has port number 179.
For additional text, see issue 46. For additional text, see issue 46.
Sue solicited additional comments, the only one was on Sue solicited additional comments, the only one was on
capitalization, so it would appear we are at consensus with this capitalization, so it would appear we are at consensus with this
issue. issue.
2.49 Explicitly Define Event Generation 2.49. Explicitly Define Event Generation
Status: Consensus Status: Consensus
Change: No Change: No
Summary: Suggested that we explicitly define BGP message processing. Summary: Suggested that we explicitly define BGP message processing.
No text proposed. There has been no further discussion on this No text proposed. There has been no further discussion on this
issue, it is assumed that the consensus is that things are ok the way issue, it is assumed that the consensus is that things are ok the way
they are. they are.
Discussion: Discussion:
skipping to change at page 62, line 29 skipping to change at page 19, line 2126
describing message processing should say where needed that a specific describing message processing should say where needed that a specific
event for the BGP session should be generated. event for the BGP session should be generated.
No text was proposed. No text was proposed.
This discussion has received no further comment. Unless someone This discussion has received no further comment. Unless someone
wants to reopen it, it is assumed it has reached a happy ending. wants to reopen it, it is assumed it has reached a happy ending.
This was discussed in the "Generial Editorial Comment" thread. This was discussed in the "Generial Editorial Comment" thread.
2.50 FSM Timers 2.50. FSM Timers
Status: Consensus Status: Consensus
Change: No Change: No
Summary: Discussion tabled, because new document version rendered the Summary: Discussion tabled, because new document version rendered the
discussion moot. discussion moot.
Discussion: Discussion:
This discussion began with a suggestion that the timers currently in This discussion began with a suggestion that the timers currently in
the FSM: the FSM:
In the 26 Aug text, I find the timer terminology still confusing. In the 26 Aug text, I find the timer terminology still confusing.
Timers can, I find, stop start restart clear set reset expire Timers can, I find, stop start restart clear set reset expire
Can be cleaned up and simplified to: Can be cleaned up and simplified to:
start with initial value (spell it out just to be sure) stop expire start with initial value (spell it out just to be sure) stop expire
A response to this proposal was, that the existing set is clear, and A response to this proposal was, that the existing set is clear, and
that the proposed set is insufficiently rich to describe a concept that the proposed set is insufficiently rich to describe a concept
like "reset" which encompasses: "Stop the timer, and reset it to its like "reset" which encompasses: "Stop the timer, and reset it to its
initial value." initial value."
This discussion reached an impasse, when Sue pointed out that the This discussion reached an impasse, when Sue pointed out that the
text had been updated, and to please review the new text. text had been updated, and to please review the new text.
This was discussed in the "FSM more words" thread. This was discussed in the "FSM more words" thread.
2.51 FSM ConnectRetryCnt 2.51. FSM ConnectRetryCnt
Status: Consensus Status: Consensus
Change: No Change: No
Summary: Discussion tabled, because new document version rendered the Summary: Discussion tabled, because new document version rendered the
discussion moot. discussion moot.
Discussion: Discussion:
This started with the observation that the ConnectRetryCnt "seems to This started with the observation that the ConnectRetryCnt "seems to
have lost its purpose." It was suggested that this be made a Session have lost its purpose." It was suggested that this be made a Session
Attribute, along with: OpenDelayTimer and DelayOpenFlag. Attribute, along with: OpenDelayTimer and DelayOpenFlag.
Curtis explained that the current purpose of the ConnectRetryCnt is Curtis explained that the current purpose of the ConnectRetryCnt is
something to be read by the MIB. He also advocated against adding something to be read by the MIB. He also advocated against adding
the additional Session Attributes. the additional Session Attributes.
2.52 Section 3: Keeping routes in Adj-RIB-In 2.52. Section 3: Keeping routes in Adj-RIB-In
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add: To allow local policy changes to have the correct Summary: Add: To allow local policy changes to have the correct
effect without resetting any BGP connections, a BGP speaker SHOULD effect without resetting any BGP connections, a BGP speaker SHOULD
either (a) retain the current version of the routes advertised to it either (a) retain the current version of the routes advertised to it
by all of its peers for the duration of the connection, or (b) make by all of its peers for the duration of the connection, or (b) make
use of the Route Refresh extension [12]. use of the Route Refresh extension [12].
Discussion: Discussion:
This thread started with a question about why we should retain routes This thread started with a question about why we should retain routes
in the Adj-RIB-In, and how it relates to the Route Refresh extension. in the Adj-RIB-In, and how it relates to the Route Refresh extension.
mrr proposed this text: mrr proposed this text:
... Therefore, a BGP speaker must either retain the current version ... Therefore, a BGP speaker must either retain the current version
of the routes advertised by all of its peers for the duration of the of the routes advertised by all of its peers for the duration of the
connection, or make use of the Route Refresh extension [12]. This is connection, or make use of the Route Refresh extension [12]. This is
necessary to allow local policy changes to have the correct effect necessary to allow local policy changes to have the correct effect
without requiring the reset of any peering sessions. without requiring the reset of any peering sessions.
If the implementation decides not to retain the current version of If the implementation decides not to retain the current version of
the routes that have been received from a peer, then Route Refresh the routes that have been received from a peer, then Route Refresh
messages should be sent whenever there is a change to local policy. messages should be sent whenever there is a change to local policy.
Yakov later suggested this text, with a slight rewording: Yakov later suggested this text, with a slight rewording:
To allow local policy changes to have the correct effect without To allow local policy changes to have the correct effect without
resetting any BGP connections, a BGP speaker SHOULD either (a) resetting any BGP connections, a BGP speaker SHOULD either (a) retain
retain the current version of the routes advertised to it by all of the current version of the routes advertised to it by all of its
its peers for the duration of the connection, or (b) make use of the peers for the duration of the connection, or (b) make use of the
Route Refresh extension [12]. Route Refresh extension [12].
mrr responded that he was fine with Yakov's suggestions. mrr responded that he was fine with Yakov's suggestions.
This was discussed in the "Proxy: comments on section 3" thread. This was discussed in the "Proxy: comments on section 3" thread.
2.53 Section 4.3 - Routes v. Destinations - Advertise 2.53. Section 4.3 - Routes v. Destinations - Advertise
Status: Consensus Status: Consensus
Change: No Change: No
Summary: The text that has reached consensus in issue 54 also Summary: The text that has reached consensus in issue 54 also
addresses this issue. addresses this issue.
Discussion: Discussion:
This issue arose out of this question to the list: This issue arose out of this question to the list:
skipping to change at page 65, line 4 skipping to change at page 19, line 2247
Shouldn't the text read "... advertise feasible [prefixes | Shouldn't the text read "... advertise feasible [prefixes |
destinations] sharing common path attribute(S)to a peer ...", destinations] sharing common path attribute(S)to a peer ...",
because: because:
1) A route is defined as quoted above from section 3.1? 1) A route is defined as quoted above from section 3.1?
or since ... or since ...
"An UPDATE message can advertise at most one set of path attributes, "An UPDATE message can advertise at most one set of path attributes,
but multiple destinations ..." but multiple destinations ..."
2) make "routes" in the original singular. 2) make "routes" in the original singular.
This was discussed in the "Review Comments: Section 4.3: "routes" vs. This was discussed in the "Review Comments: Section 4.3: "routes" vs.
destinations - advertise" thread. destinations - advertise" thread.
The text that has reached consensus in issue 54 also addresses this The text that has reached consensus in issue 54 also addresses this
issue. issue.
2.54 Section 4.3 - Routes v. Destinations - Withdraw 2.54. Section 4.3 - Routes v. Destinations - Withdraw
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Change the definition of "route" as it currently stands to: Summary: Change the definition of "route" as it currently stands to:
For the purpose of this protocol, a route is defined as a unit of For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a information that pairs a set of destinations with the attributes of a
path to those destinations. The set of destinations are systems whose path to those destinations. The set of destinations are systems
IP addresses are contained in one IP address prefix carried in the whose IP addresses are contained in one IP address prefix carried in
Network Layer Reachability Information (NLRI) field of an UPDATE the Network Layer Reachability Information (NLRI) field of an UPDATE
message and the path is the information reported in the path message and the path is the information reported in the path
attributes field of the same UPDATE message. attributes field of the same UPDATE message.
Multiple routes that have the same path attributes can be advertised Multiple routes that have the same path attributes can be advertised
in a single UPDATE message by including multiple prefixes in the NLRI in a single UPDATE message by including multiple prefixes in the NLRI
field of the UPDATE message. field of the UPDATE message.
Discussion: Discussion:
This issue was brought up with this question: This issue was brought up with this question:
skipping to change at page 65, line 44 skipping to change at page 19, line 2288
When I read these two paragraphs at the end of section 4.3: When I read these two paragraphs at the end of section 4.3:
"An UPDATE message can list multiple routes to be withdrawn from "An UPDATE message can list multiple routes to be withdrawn from
service. Each such route is identified by its destination (expressed service. Each such route is identified by its destination (expressed
as an IP prefix), which unambiguously identifies the route in the as an IP prefix), which unambiguously identifies the route in the
context of the BGP speaker - BGP speaker connection to which it has context of the BGP speaker - BGP speaker connection to which it has
been previously advertised. been previously advertised.
An UPDATE message might advertise only routes to be withdrawn from An UPDATE message might advertise only routes to be withdrawn from
service, in which case it will not include path attributes or Network service, in which case it will not include path attributes or Network
Layer Reachability Information. Conversely, it may advertise only a Layer Reachability Information. Conversely, it may advertise only a
feasible route, in which case the WITHDRAWN ROUTES field need not be feasible route, in which case the WITHDRAWN ROUTES field need not be
present." present."
It reads as if one must withdraw the _set of destinations_ advertised It reads as if one must withdraw the _set of destinations_ advertised
with the route instead of just one or more destinations since route with the route instead of just one or more destinations since route
is defined in section 3.1 as: is defined in section 3.1 as:
"For the purpose of this protocol, a route is defined as a unit of "For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a information that pairs a set of destinations with the attributes of a
path to those destinations. The set of destinations are the systems path to those destinations. The set of destinations are the systems
skipping to change at page 67, line 4 skipping to change at page 19, line 2343
This definition allows multiple routes to be advertised in a single This definition allows multiple routes to be advertised in a single
UPDATE message by including multiple prefixes in the NLRI field of UPDATE message by including multiple prefixes in the NLRI field of
the UPDATE. All such prefixes must be associated with the same set the UPDATE. All such prefixes must be associated with the same set
of path attributes." of path attributes."
Yakov suggested some minor rewording: Yakov suggested some minor rewording:
For the purpose of this protocol, a route is defined as a unit of For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a information that pairs a set of destinations with the attributes of a
path to those destinations. The set of destinations are systems whose path to those destinations. The set of destinations are systems
IP addresses are contained in one IP address prefix carried in the whose IP addresses are contained in one IP address prefix carried in
Network Layer Reachability Information (NLRI) field of an UPDATE the Network Layer Reachability Information (NLRI) field of an UPDATE
message and the path is the information reported in the path message and the path is the information reported in the path
attributes field of the same UPDATE message. attributes field of the same UPDATE message.
Multiple routes that have the same path attributes can be advertised Multiple routes that have the same path attributes can be advertised
in a single UPDATE message by including multiple prefixes in the NLRI in a single UPDATE message by including multiple prefixes in the NLRI
field of the UPDATE message. field of the UPDATE message.
Both Jeff and Matt responded that they liked this text. Both Jeff and Matt responded that they liked this text.
2.55) Section 4.3 - Description of AS_PATH length 2.55. Section 4.3 - Description of AS_PATH length
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Replace: Summary: Replace:
Path segment length is a 1-octet long field containing the number of Path segment length is a 1-octet long field containing the number of
ASs in the path segment value field. ASs in the path segment value field.
With: With:
skipping to change at page 68, line 29 skipping to change at page 19, line 2415
How about: "Path segment length is a 1-octet long field containing How about: "Path segment length is a 1-octet long field containing
the number of ASs (which is half the number of octets since each AS the number of ASs (which is half the number of octets since each AS
is 2 octets) in the path segment value field (also note that the path is 2 octets) in the path segment value field (also note that the path
may contain more than 1 segment). may contain more than 1 segment).
Jeff replied that he preferred Yakov's text, but without the "but". Jeff replied that he preferred Yakov's text, but without the "but".
Yakov agreed to that. Andrew also agreed, and asked if there were Yakov agreed to that. Andrew also agreed, and asked if there were
any objections to moving this issue into consensus. There were no any objections to moving this issue into consensus. There were no
objections. objections.
2.56 Section 6 - BGP Error Handling 2.56. Section 6 - BGP Error Handling
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: There are a variety of updates to the text that are best Summary: There are a variety of updates to the text that are best
described in the discussion section. described in the discussion section.
Discussion: Discussion:
This discussion began with some suggestions on ways to clarify the This discussion began with some suggestions on ways to clarify the
text in section 6 dealing with error handling. The original text in section 6 dealing with error handling. The original
comments, and Yakov's response are below: comments, and Yakov's response are below:
> At the beginning of Section 6. BGP Error Handling: > At the beginning of Section 6. BGP Error Handling:
> >
> >
> "When any of the conditions described here are detected, a > "When any of the conditions described here are detected, a
> NOTIFICATION message with the indicated Error Code, Error > NOTIFICATION message with the indicated Error Code, Error Subcode,
Subcode, > and Data fields is sent, and the BGP connection is closed."
> and Data fields is sent, and the BGP connection is closed."
> >
> There are several cases where the conditions described in this > There are several cases where the conditions described in this
section section
> do not result in the BGP connection being closed. These conditions > do not result in the BGP connection being closed. These conditions
> should either state that the connection stays up. Another > should either state that the connection stays up. Another
possibility possibility
> is to remove "and the BGP connection is closed." above, and for > is to remove "and the BGP connection is closed." above, and for
each each
> listed connection, state what happens to the BGP connection. This > listed connection, state what happens to the BGP connection. This
> already takes place for certain conditions, but isn't done > already takes place for certain conditions, but isn't done
skipping to change at page 69, line 26 skipping to change at page 19, line 2460
and Data fields is sent, and the BGP connection is closed, unless it and Data fields is sent, and the BGP connection is closed, unless it
is explicitly stated that no NOTIFICATION message is to be sent and is explicitly stated that no NOTIFICATION message is to be sent and
the BGP connection is not to be close. the BGP connection is not to be close.
> I tried to list what I found (which may be wrong or incomplete) > I tried to list what I found (which may be wrong or incomplete)
below: below:
> >
> >
> "If the NEXT_HOP attribute is semantically incorrect, the error > "If the NEXT_HOP attribute is semantically incorrect, the error
should should
> be logged, and the route should be ignored. In this case, no > be logged, and the route should be ignored. In this case, no
> NOTIFICATION message should be sent." > NOTIFICATION message should be sent."
> >
> * Append the connection is not closed. > * Append the connection is not closed.
Done. Done.
> >
> "(a) discard new address prefixes from the neighbor, or (b) > "(a) discard new address prefixes from the neighbor, or (b)
terminate terminate
> the BGP peering with the neighbor." > the BGP peering with the neighbor."
> >
> * Append "the connection is not closed" to case (a) > * Append "the connection is not closed" to case (a)
added "(while maintaining BGP peering with the neighbor)" to case added "(while maintaining BGP peering with the neighbor)" to case
(a). (a).
> >
> "If the autonomous system number appears in the AS path the > "If the autonomous system number appears in the AS path the
> route may be stored in the Adj-RIB-In," > route may be stored in the Adj-RIB-In,"
> >
> * append and the BGP connection stays up. > * append and the BGP connection stays up.
> >
> "but unless the router is configured to accept routes with its > "but unless the router is configured to accept routes with its
> own autonomous system in the AS path, the route shall not be > own autonomous system in the AS path, the route shall not be
> passed to the BGP Decision Process." > passed to the BGP Decision Process."
I would suggest to move this text to Section 9 (UPDATE message I would suggest to move this text to Section 9 (UPDATE message
handling), as receiving a route with your own AS in the AS path isn't handling), as receiving a route with your own AS in the AS path isn't
really an error. It is just that usually (but not always) you can't really an error. It is just that usually (but not always) you can't
put this route in your Adj-RIB-In. put this route in your Adj-RIB-In.
> * Q1) does the BGP connection stay up? > * Q1) does the BGP connection stay up?
yes. yes.
> * Q2) what if the router isn't configured to accept routes with its > * Q2) what if the router isn't configured to accept routes with its
> own AS in the AS path? One _may_ store the route in Adj-RIB-In, > own AS in the AS path? One _may_ store the route in Adj-RIB-In,
but but
> if one doesn't want to? > if one doesn't want to?
So, don't store them. So, don't store them.
> Is the BGP connection closed? If so, what subcode? > Is the BGP connection closed? If so, what subcode?
The connection is *not* closed. The connection is *not* closed.
> "If an optional attribute is recognized, then the value of this > "If an optional attribute is recognized, then the value of this
> attribute is checked. If an error is detected, the attribute is > attribute is checked. If an error is detected, the attribute is
> discarded, and the Error Subcode is set to Optional Attribute > discarded, and the Error Subcode is set to Optional Attribute
Error. Error.
> The Data field contains the attribute (type, length and > The Data field contains the attribute (type, length and value)."
value)."
> >
> * Append and the BGP connection stays up after "the attribute is > * Append and the BGP connection stays up after "the attribute is
discarded". discarded".
Since you have to close the connection, you have to discard all the Since you have to close the connection, you have to discard all the
routes received via this connection, including the route with the routes received via this connection, including the route with the
incorrect attribute. So, there is no need to say that "the attribute incorrect attribute. So, there is no need to say that "the attribute
is discarded". is discarded".
There have been no objections to the updates listed above. This There have been no objections to the updates listed above. This
issue seems to have reached a happy ending, so it has been moved into issue seems to have reached a happy ending, so it has been moved into
consensus. consensus.
This was discussed in the "-17 review Section 6 - BGP Error This was discussed in the "-17 review Section 6 - BGP Error
Handling." thread. Handling." thread.
2.57 Section 6.2 - Hold timer as Zero 2.57. Section 6.2 - Hold timer as Zero
Status: Consensus Status: Consensus
Change: No Change: No
Summary: It was suggested that we update the text to say that we MUST Summary: It was suggested that we update the text to say that we MUST
reject hold time values of zero. It was pointed out that this is not reject hold time values of zero. It was pointed out that this is not
the case and the text should say the way it is. the case and the text should say the way it is.
Discussion: Discussion:
In Section 6.2 on OPEN message error handling: In Section 6.2 on OPEN message error handling:
If the Hold Time field of the OPEN message is unacceptable, then the If the Hold Time field of the OPEN message is unacceptable, then the
Error Subcode MUST be set to Unacceptable Hold Time. An Error Subcode MUST be set to Unacceptable Hold Time. An
implementation MUST reject Hold Time values of one or two seconds. implementation MUST reject Hold Time values of one or two seconds.
I feel that text similar to: I feel that text similar to:
"An implementation MUST also reject Hold Time values of zero received "An implementation MUST also reject Hold Time values of zero received
from a peer in a different AS" should be considered for completeness. from a peer in a different AS" should be considered for completeness.
A number of respondents pointed out that zero hold time is legitimate A number of respondents pointed out that zero hold time is legitimate
under certain circumstances. under certain circumstances.
This was discussed in the "-17 review, Section 6.2 - must reject hold This was discussed in the "-17 review, Section 6.2 - must reject hold
time" thread. time" thread.
2.58 Deprecation of ATOMIC_AGGREGATE 2.58. Deprecation of ATOMIC_AGGREGATE
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: For new text, please see the end of the discussion. Summary: For new text, please see the end of the discussion.
Discussion: Discussion:
Jeff opened this discussion with: Jeff opened this discussion with:
Deprecation of ATOMIC_AGGREGATE: Deprecation of ATOMIC_AGGREGATE:
[This is a summary of some discussions from those who have "been [This is a summary of some discussions from those who have "been
there, done that" during the CIDR deployment period and also comments there, done that" during the CIDR deployment period and also comments
from network operators on the NANOG list.] from network operators on the NANOG list.]
skipping to change at page 72, line 6 skipping to change at page 19, line 2583
Additionally, there were some transition issues when aggregated Additionally, there were some transition issues when aggregated
networks would need to be de-aggregated and re-advertised into a networks would need to be de-aggregated and re-advertised into a
classful routing mesh such as BGP-3. classful routing mesh such as BGP-3.
The ATOMIC_AGGREGATE flag was intended to prevent a route from being The ATOMIC_AGGREGATE flag was intended to prevent a route from being
de-aggregated when de-aggregation would introduce routing loops. de-aggregated when de-aggregation would introduce routing loops.
Note that de-aggregation in this context specifically means making a Note that de-aggregation in this context specifically means making a
less specific route into one or more more-specific routes. less specific route into one or more more-specific routes.
The current BGP draft has two situations where ATOMIC_AGGREGATE The current BGP draft has two situations where ATOMIC_AGGREGATE
should be appended to a route: 1. When a route's AS_PATH is should be appended to a route: 1. When a route's AS_PATH is
intentionally truncated, such as what happens by default on Cisco's, intentionally truncated, such as what happens by default on Cisco's,
or using the "brief" option on GateD. Juniper has a similar feature or using the "brief" option on GateD. Juniper has a similar feature
- I'm unsure of the default. 2. When two routes are implicitly - I'm unsure of the default. 2. When two routes are implicitly
aggregated in the LocRib such that a more specific route is not aggregated in the LocRib such that a more specific route is not
selected when a less specific route is from a given peer. selected when a less specific route is from a given peer.
Note that this particular feature is not implemented anywhere that I Note that this particular feature is not implemented anywhere that I
am aware of. am aware of.
3. There is a third case not covered by the specification: Implicit 3. There is a third case not covered by the specification: Implicit
aggregation on export - a more specific route is not exported and aggregation on export - a more specific route is not exported and
only a less specific one is. only a less specific one is.
When network operators were asked about de-aggregation practices, I When network operators were asked about de-aggregation practices, I
received about 40 responses. The majority of these responses received about 40 responses. The majority of these responses
confused de-aggregation with leaking existing more-specific routes confused de-aggregation with leaking existing more-specific routes
that are used internally rather than explicitly de-aggregating a that are used internally rather than explicitly de-aggregating a
less-specific route. less-specific route.
There were a very few cases of explicit de-aggregation. One form was There were a very few cases of explicit de-aggregation. One form was
skipping to change at page 72, line 38 skipping to change at page 19, line 2615
by advertising IP space that didn't belong to them - leaked more by advertising IP space that didn't belong to them - leaked more
specifics alleviated the problem in many cases. (Note that this is a specifics alleviated the problem in many cases. (Note that this is a
security issue in the routing system.) security issue in the routing system.)
The second case was de-aggregating routes internally (and sending the The second case was de-aggregating routes internally (and sending the
routes via IBGP marked with NO-ADVERTISE) for purposes of traffic routes via IBGP marked with NO-ADVERTISE) for purposes of traffic
engineering routing internally where a given upstream failed to engineering routing internally where a given upstream failed to
provide enough routing information to allow traffic flows to be provide enough routing information to allow traffic flows to be
optimized based on supplied prefixes. optimized based on supplied prefixes.
My conclusions to this are: 1. De-aggregation is not a common My conclusions to this are: 1. De-aggregation is not a common
practice. 2. It is no longer a major concern since classful inter- practice. 2. It is no longer a major concern since classful inter-
domain routing is pretty much gone. 3. The spec doesn't match domain routing is pretty much gone. 3. The spec doesn't match
reality and should be corrected. reality and should be corrected.
My suggestions are thus this: Section 5.1.6 should be updated as My suggestions are thus this: Section 5.1.6 should be updated as
follows: ATOMIC_AGGREGATE is a well-known discretionary attribute. follows: ATOMIC_AGGREGATE is a well-known discretionary attribute.
Its use is deprecated. Its use is deprecated.
When a router explicitly aggregates several routes for the purpose of When a router explicitly aggregates several routes for the purpose of
advertisement to a particular peer, and the AS_PATH of the aggregated advertisement to a particular peer, and the AS_PATH of the aggregated
route excludes at least some of the AS numbers present in the AS_PATH route excludes at least some of the AS numbers present in the AS_PATH
of the routes that are aggregated (usually due to truncation), the of the routes that are aggregated (usually due to truncation), the
aggregated route, when advertised to the peer, MUST include the aggregated route, when advertised to the peer, MUST include the
ATOMIC_AGGREGATE attribute. ATOMIC_AGGREGATE attribute.
Section 9.1.4 should be updated as follows: Section 9.1.4 should be updated as follows:
Original text: Original text: If a BGP speaker receives overlapping routes, the
If a BGP speaker receives overlapping routes, the Decision Decision Process MUST consider both routes based on the configured
Process acceptance policy. If both a less and a more specific route are
MUST consider both routes based on the configured acceptance accepted, then the Decision Process MUST either install both the less
policy. and the more specific routes or it MUST aggregate the two routes and
If both a less and a more specific route are accepted, then the install the aggregated route, provided that both routes have the same
Decision Process MUST either install both the less and the more value of the NEXT_HOP attribute.
specific routes or it MUST aggregate the two routes and install
the
aggregated route, provided that both routes have the same value
of
the NEXT_HOP attribute.
If a BGP speaker chooses to aggregate, then it MUST add If a BGP speaker chooses to aggregate, then it MUST add
ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute to the route. A route that carries
ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
NLRI of this route can not be made more specific. Forwarding NLRI of this route can not be made more specific. Forwarding along
along such a route does not guarantee that IP packets will actually
such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route.
traverse only ASs listed in the AS_PATH attribute of the route.
Replace with: Replace with:
It is common practice that more specific routes are often implicitly It is common practice that more specific routes are often implicitly
aggregated by selecting or advertising only a less-specific route aggregated by selecting or advertising only a less-specific route
when overlapping routes are present. As such, all routes SHOULD be when overlapping routes are present. As such, all routes SHOULD be
treated as if ATOMIC_AGGREGATE is present and not be made more treated as if ATOMIC_AGGREGATE is present and not be made more
specific (de-aggregated). De-aggregation may lead to routing loops. specific (de-aggregated). De-aggregation may lead to routing loops.
Section 9.2.2 should remain as it is. Section 9.2.2 should remain as it is.
skipping to change at page 74, line 47 skipping to change at page 19, line 2716
truncation of a AS_PATH is the best we'll get out of it - and it truncation of a AS_PATH is the best we'll get out of it - and it
matches current implementations. matches current implementations.
Jonathan agreed with Curtis' idea that we should just move Jonathan agreed with Curtis' idea that we should just move
ATOMIC_AGGREGATE to informational. ATOMIC_AGGREGATE to informational.
Curtis proposed this text: Curtis proposed this text:
This existing text is fine: This existing text is fine:
f) ATOMIC_AGGREGATE (Type Code 6) f) ATOMIC_AGGREGATE (Type Code 6)
ATOMIC_AGGREGATE is a well-known discretionary attribute of ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0.
length 0. Usage of this attribute is described in 5.1.6. Usage of this attribute is described in 5.1.6.
This is the existing text that we are considering changing: This is the existing text that we are considering changing:
5.1.6 ATOMIC_AGGREGATE 5.1.6 ATOMIC_AGGREGATE
ATOMIC_AGGREGATE is a well-known discretionary attribute. ATOMIC_AGGREGATE is a well-known discretionary attribute.
When a router aggregates several routes for the purpose of When a router aggregates several routes for the purpose of
advertisement to a particular peer, and the AS_PATH of the aggregated advertisement to a particular peer, and the AS_PATH of the aggregated
route excludes at least some of the AS numbers present in the AS_PATH route excludes at least some of the AS numbers present in the AS_PATH
skipping to change at page 76, line 21 skipping to change at page 19, line 2785
destinations, as specified in the NLRI of the route, while having the destinations, as specified in the NLRI of the route, while having the
loop-free property, may not be the path specified in the AS_PATH loop-free property, may not be the path specified in the AS_PATH
attribute of the route. attribute of the route.
Diffs (for reader convenience): Diffs (for reader convenience):
@@ -4,13 +4,19 @@ ATOMIC_AGGREGATE is a well-known discretionary @@ -4,13 +4,19 @@ ATOMIC_AGGREGATE is a well-known discretionary
attribute. attribute.
When a router aggregates several routes for the purpose of When a router aggregates several routes for the purpose of
- advertisement to a particular peer, and the AS_PATH of the - advertisement to a particular peer, and the AS_PATH of the
- aggregated route excludes at least some of the AS numbers - aggregated route excludes at least some of the AS numbers
- present in the AS_PATH of the routes that are aggregated, - present in the AS_PATH of the routes that are aggregated,
- the aggregated route, when advertised to the peer, MUST - the aggregated route, when advertised to the peer, MUST
- include the ATOMIC_AGGREGATE attribute. - include the ATOMIC_AGGREGATE attribute.
+ advertisement to a particular peer, the AS_PATH of the + advertisement to a particular peer, the AS_PATH of the
+ aggregated route normally includes an AS_SET formed from the + aggregated route normally includes an AS_SET formed from the
+ set of AS from which the aggregate was formed. In many cases + set of AS from which the aggregate was formed. In many cases
+ the network administrator can determine that the aggregate can + the network administrator can determine that the aggregate can
+ safely be advertised without the AS_SET and not form route loops. + safely be advertised without the AS_SET and not form route loops.
+ +
+ If an aggregate excludes at least some of the AS numbers present + If an aggregate excludes at least some of the AS numbers present
+ in the AS_PATH of the routes that are aggregated as a result of + in the AS_PATH of the routes that are aggregated as a result of
+ dropping the AS_SET, the aggregated route, when advertised to the + dropping the AS_SET, the aggregated route, when advertised to the
+ peer, SHOULD include the ATOMIC_AGGREGATE attribute. + peer, SHOULD include the ATOMIC_AGGREGATE attribute.
A BGP speaker that receives a route with the ATOMIC_AGGREGATE A BGP speaker that receives a route with the ATOMIC_AGGREGATE
- attribute MUST NOT remove the attribute from the route when - attribute MUST NOT remove the attribute from the route when
+ attribute SHOULD NOT remove the attribute from the route when + attribute SHOULD NOT remove the attribute from the route when
+ propagating it to other speakers. + propagating it to other speakers.
A BGP speaker that receives a route with the ATOMIC_AGGREGATE A BGP speaker that receives a route with the ATOMIC_AGGREGATE
Current text in 9.1.4: Current text in 9.1.4:
If a BGP speaker chooses to aggregate, then it MUST add If a BGP speaker chooses to aggregate, then it MUST add
ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute to the route. A route that carries
ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
NLRI of this route can not be made more specific. Forwarding along NLRI of this route can not be made more specific. Forwarding along
such a route does not guarantee that IP packets will actually such a route does not guarantee that IP packets will actually
traverse only ASs listed in the AS_PATH attribute of the route. traverse only ASs listed in the AS_PATH attribute of the route.
Change to: Change to:
If a BGP speaker chooses to aggregate, then it SHOULD either include If a BGP speaker chooses to aggregate, then it SHOULD either include
all AS used to form the aggregate in an AS_SET or add the all AS used to form the aggregate in an AS_SET or add the
ATOMIC_AGGREGATE attribute to the route. This attribute is now ATOMIC_AGGREGATE attribute to the route. This attribute is now
primarily informational. With the elimination of IP routing primarily informational. With the elimination of IP routing
protocols that do not support classless routing and the elimination protocols that do not support classless routing and the elimination
of router and host implementations that do not support classless of router and host implementations that do not support classless
routing, there is no longer a need to deaggregate. Routes SHOULD NOT routing, there is no longer a need to deaggregate. Routes SHOULD NOT
be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in
particular MUST NOT be de-aggregated. That is, the NLRI of this route particular MUST NOT be de-aggregated. That is, the NLRI of this
can not be made more specific. Forwarding along such a route does not route can not be made more specific. Forwarding along such a route
guarantee that IP packets will actually traverse only ASs listed in does not guarantee that IP packets will actually traverse only ASs
the AS_PATH attribute of the route. listed in the AS_PATH attribute of the route.
This text in 9.2.2.2 need not change. This text in 9.2.2.2 need not change.
ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has
ATOMIC_AGGREGATE path attribute, then the aggregated route shall have ATOMIC_AGGREGATE path attribute, then the aggregated route shall have
this attribute as well. this attribute as well.
The appendix need not change: The appendix need not change:
Appendix 1. Comparison with RFC1771 Appendix 1. Comparison with RFC1771
[...] [...]
Clarifications to the use of the ATOMIC_AGGREGATE attribute. Clarifications to the use of the ATOMIC_AGGREGATE attribute.
This might be a bit more wordy that is necessary. It does address This might be a bit more wordy that is necessary. It does address
the objections to keeping ATOMIC_AGGREGATE by making the MUST into the objections to keeping ATOMIC_AGGREGATE by making the MUST into
SHOULD, and explaining that ATOMIC_AGGREGATE is now primarily SHOULD, and explaining that ATOMIC_AGGREGATE is now primarily
informational. informational.
skipping to change at page 79, line 8 skipping to change at page 19, line 2916
A BGP speaker that receives a route with the ATOMIC_AGGREGATE A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute needs to be cognizant of the fact that the actual path to attribute needs to be cognizant of the fact that the actual path to
destinations, as specified in the NLRI of the route, while having the destinations, as specified in the NLRI of the route, while having the
loop-free property, may not be the path specified in the AS_PATH loop-free property, may not be the path specified in the AS_PATH
attribute of the route. attribute of the route.
In 9.1.4 replace: In 9.1.4 replace:
If a BGP speaker chooses to aggregate, then it MUST add If a BGP speaker chooses to aggregate, then it MUST add
ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute to the route. A route that carries
ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
NLRI of this route can not be made more specific. Forwarding along NLRI of this route can not be made more specific. Forwarding along
such a route does not guarantee that IP packets will actually such a route does not guarantee that IP packets will actually
traverse only ASs listed in the AS_PATH attribute of the route. traverse only ASs listed in the AS_PATH attribute of the route.
with: with:
If a BGP speaker chooses to aggregate, then it SHOULD either include If a BGP speaker chooses to aggregate, then it SHOULD either include
all AS used to form the aggregate in an AS_SET or add the all AS used to form the aggregate in an AS_SET or add the
ATOMIC_AGGREGATE attribute to the route. This attribute is now ATOMIC_AGGREGATE attribute to the route. This attribute is now
primarily informational. With the elimination of IP routing primarily informational. With the elimination of IP routing
protocols that do not support classless routing and the elimination protocols that do not support classless routing and the elimination
of router and host implementations that do not support classless of router and host implementations that do not support classless
routing, there is no longer a need to deaggregate. Routes SHOULD NOT routing, there is no longer a need to deaggregate. Routes SHOULD NOT
be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in be de-aggregated. A route that carries ATOMIC_AGGREGATE attribute in
particular MUST NOT be de-aggregated. That is, the NLRI of this route particular MUST NOT be de-aggregated. That is, the NLRI of this
can not be made more specific. Forwarding along such a route does not route can not be made more specific. Forwarding along such a route
guarantee that IP packets will actually traverse only ASs listed in does not guarantee that IP packets will actually traverse only ASs
the AS_PATH attribute of the route. listed in the AS_PATH attribute of the route.
This met with agreement. This issue is at consensus. This met with agreement. This issue is at consensus.
2.59 Section 4.3 - Move text 2.59. Section 4.3 - Move text
Status: Consensus Status: Consensus
Change: Yes (minimal) Change: Yes (minimal)
Summary: Update indentation to allow a new "subsection" heading. Summary: Update indentation to allow a new "subsection" heading.
Otherwise no change. Otherwise no change.
Discussion: Discussion:
This began with this suggestion: This began with this suggestion:
skipping to change at page 80, line 11 skipping to change at page 19, line 2968
Jonathan agreed, and suggested this text: Jonathan agreed, and suggested this text:
" The minimum length of the UPDATE message is 23 octets -- 19 octets " The minimum length of the UPDATE message is 23 octets -- 19 octets
for the fixed header + 2 octets for the Withdrawn Routes Length + 2 for the fixed header + 2 octets for the Withdrawn Routes Length + 2
octets for the Total Path Attribute Length (the value of Withdrawn octets for the Total Path Attribute Length (the value of Withdrawn
Routes Length is 0 and the value of Total Path Attribute Length is Routes Length is 0 and the value of Total Path Attribute Length is
0)." 0)."
Should be moved up to just after Should be moved up to just after
"... the Total Path Attribute Length field and the "... the Total Path Attribute Length field and the Withdrawn Routes
Withdrawn Routes Length field." Length field."
Yakov responded to this with: Yakov responded to this with:
Disagree, as "... the Total Path Attribute Length field and the Disagree, as "... the Total Path Attribute Length field and the
Withdrawn Routes Length field." explains how to calculate the length Withdrawn Routes Length field." explains how to calculate the length
of NLRI field (and therefore is part of the NLRI field description), of NLRI field (and therefore is part of the NLRI field description),
while "The minimum length of the UPDATE message is 23 octets...." while "The minimum length of the UPDATE message is 23 octets...." has
has to do with the length of the UPDATE message. to do with the length of the UPDATE message.
Jonathan also suggested: Jonathan also suggested:
" the value of Withdrawn Routes Length is 0 and the value of Total " the value of Withdrawn Routes Length is 0 and the value of Total
Path Attribute Length is 0)." Path Attribute Length is 0)."
Should be changed to Should be changed to
" the min. value of Withdrawn Routes Length is 0 and the min. value " the min. value of Withdrawn Routes Length is 0 and the min. value
of Total Path Attribute Length is 0)." of Total Path Attribute Length is 0)."
skipping to change at page 80, line 46 skipping to change at page 19, line 3003
but talks about the value of these fields in the case of a min length but talks about the value of these fields in the case of a min length
UPDATE message. UPDATE message.
After Yakov's response and a posting to the list asking that this be After Yakov's response and a posting to the list asking that this be
moved to consensus, there were no objections, so this is moved to moved to consensus, there were no objections, so this is moved to
consensus. consensus.
This is discussed in the "Review: Comments: Section 4.3: UPDATE min This is discussed in the "Review: Comments: Section 4.3: UPDATE min
length" thread. length" thread.
2.60 Section 4.3 - Path Attributes 2.60. Section 4.3 - Path Attributes
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Make this change to clarify path attributes in an UPDATE: Summary: Make this change to clarify path attributes in an UPDATE:
To correct the confusion I propose to replace: To correct the confusion I propose to replace:
A variable length sequence of path attributes is present in every A variable length sequence of path attributes is present in every
UPDATE. UPDATE.
skipping to change at page 82, line 11 skipping to change at page 19, line 3064
A variable length sequence of path attributes is present in every A variable length sequence of path attributes is present in every
UPDATE message, except for an UPDATE message that carries only the UPDATE message, except for an UPDATE message that carries only the
withdrawn routes. withdrawn routes.
There was one agreement with this proposal. There was one agreement with this proposal.
This is discussed in the thread: "Review: Section 4.3 - Path This is discussed in the thread: "Review: Section 4.3 - Path
Attributes" Attributes"
2.61 Next Hop for Redistributed Routes 2.61. Next Hop for Redistributed Routes
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: More clearly specify the behavior of NEXT_HOP modification, Summary: More clearly specify the behavior of NEXT_HOP modification,
for the text see the end of the discussion. for the text see the end of the discussion.
Discussion: Discussion:
Jonathan began this thread with: Jonathan began this thread with:
I propose adding: I propose adding:
"When announcing a locally originated route to an internal peer, the "When announcing a locally originated route to an internal peer, the
BGP speaker should use as the NEXT_HOP the interface address of the BGP speaker should use as the NEXT_HOP the interface address of the
skipping to change at page 82, line 48 skipping to change at page 19, line 3101
There has been no discussion on this. There has been no discussion on this.
This is discussed in the "Next hop for redistributed routes" thread. This is discussed in the "Next hop for redistributed routes" thread.
Issue 14 closed in favor of this issue. Issue 14 closed in favor of this issue.
In response to Yakov's call for input, Michael responded that: In response to Yakov's call for input, Michael responded that:
Section 5.1.3 explicitly states what to do when originating to an Section 5.1.3 explicitly states what to do when originating to an
external peer. #2 covers one hop away, #3 covers more than on hop external peer. #2 covers one hop away, #3 covers more than on hop
away. #1 talks about sending to an iBGP peer, but only when away. #1 talks about sending to an iBGP peer, but only when
propagating a route received from an eBGP peer. propagating a route received from an eBGP peer.
1) When sending a message to an internal peer, the BGP speaker should 1) When sending a message to an internal peer, the BGP speaker should
not modify the NEXT_HOP attribute, unless it has been explicitly not modify the NEXT_HOP attribute, unless it has been explicitly
configured to announce its own IP address as the NEXT_HOP. configured to announce its own IP address as the NEXT_HOP.
Text similar to #2 should be added, in their own bullet items to #1 Text similar to #2 should be added, in their own bullet items to #1
such as what was suggested by Jonathan Natale (text is above.) such as what was suggested by Jonathan Natale (text is above.)
Yakov replied with this: Yakov replied with this:
skipping to change at page 83, line 25 skipping to change at page 19, line 3125
1) When sending a message to an internal peer, the BGP speaker should 1) When sending a message to an internal peer, the BGP speaker should
not modify the NEXT_HOP attribute, unless it has been explicitly not modify the NEXT_HOP attribute, unless it has been explicitly
configured to announce its own IP address as the NEXT_HOP. configured to announce its own IP address as the NEXT_HOP.
with: with:
1) When sending a message to an internal peer, if the route is not 1) When sending a message to an internal peer, if the route is not
locally originated the BGP speaker should not modify the NEXT_HOP locally originated the BGP speaker should not modify the NEXT_HOP
attribute, unless it has been explicitly configured to announce its attribute, unless it has been explicitly configured to announce its
own IP address as the NEXT_HOP. When announcing a locally originated own IP address as the NEXT_HOP. When announcing a locally originated
route to an internal peer, the BGP speaker should use as the NEXT_HOP route to an internal peer, the BGP speaker should use as the NEXT_HOP
the interface address of the router through which the announced the interface address of the router through which the announced
network is reachable for the speaker; if the route is directly network is reachable for the speaker; if the route is directly
connected to the speaker, or the interface address of the router connected to the speaker, or the interface address of the router
through which the announced network is reachable for the speaker is through which the announced network is reachable for the speaker is
the internal peer's address, then the BGP speaker should use for the the internal peer's address, then the BGP speaker should use for the
NEXT_HOP attribute its own IP address (the address of the interface NEXT_HOP attribute its own IP address (the address of the interface
that is used to reach the peer). that is used to reach the peer).
And stated the change would be made if there were no objections. And stated the change would be made if there were no objections.
There have been no objections, so this is at consensus. There have been no objections, so this is at consensus.
2.62 Deprecate BGP Authentication Optional Parameter from RFC1771 2.62. Deprecate BGP Authentication Optional Parameter from RFC1771
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: We are at consensus, in that we agree that we should Summary: We are at consensus, in that we agree that we should
deprecate the BGP Authentication Optional Parameter as described in deprecate the BGP Authentication Optional Parameter as described in
RFC1771 in favor of the mechanism described in RFC2385. The textual RFC1771 in favor of the mechanism described in RFC2385. The textual
changes are listed at the end of the discussion section of this changes are listed at the end of the discussion section of this
issue. issue.
Discussion: Discussion:
skipping to change at page 85, line 9 skipping to change at page 19, line 3205
should deprecate the BGP Authentication Optional Parameter from should deprecate the BGP Authentication Optional Parameter from
RFC1771. RFC1771.
Ok, after some discussion, this is a list of the text that we are Ok, after some discussion, this is a list of the text that we are
adding, changing or removing: adding, changing or removing:
1) Remove the reference to the authentication optional parameter: 1) Remove the reference to the authentication optional parameter:
I would suggest to remove the following text from the draft: I would suggest to remove the following text from the draft:
This document defines the following Optional Parameters: This document defines the following Optional Parameters:
a) Authentication Information (Parameter Type 1): a) Authentication Information (Parameter Type 1):
This optional parameter may be used to authenticate a BGP This optional parameter may be used to authenticate a BGP peer. The
peer. The Parameter Value field contains a 1-octet Parameter Value field contains a 1-octet Authentication Code followed
Authentication Code followed by a variable length by a variable length Authentication Data.
Authentication Data.
0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | Auth. Code |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |
| Auth. Code | Authentication Data | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code: Authentication Code:
This 1-octet unsigned integer indicates the This 1-octet unsigned integer indicates the authentication mechanism
authentication mechanism being used. Whenever an being used. Whenever an authentication mechanism is specified for
authentication mechanism is specified for use within use within BGP, three things must be included in the specification:
BGP, three things must be included in the
specification:
- the value of the Authentication Code which indicates - the value of the Authentication Code which indicates use of the
use of the mechanism, mechanism, - the form and meaning of the Authentication Data, and -
- the form and meaning of the Authentication Data, and the algorithm for computing values of Marker fields.
- the algorithm for computing values of Marker fields.
Note that a separate authentication mechanism may be Note that a separate authentication mechanism may be used in
used in establishing the transport level connection. establishing the transport level connection.
Authentication Data: Authentication Data:
Authentication Data is a variable length field that is Authentication Data is a variable length field that is interpreted
interpreted according to the value of the according to the value of the Authentication Code field.
Authentication Code field.
2) Update the introduction: 2) Update the introduction:
In section 2 (Introduction), sixth paragraph In section 2 (Introduction), sixth paragraph
From: From:
BGP runs over a reliable transport protocol. This eliminates the need BGP runs over a reliable transport protocol. This eliminates the
to implement explicit update fragmentation, retransmission, need to implement explicit update fragmentation, retransmission,
acknowledgment, and sequencing. Any authentication scheme used by the acknowledgment, and sequencing. Any authentication scheme used by
transport protocol (e.g., RFC2385 [10]) may be used in addition to the transport protocol (e.g., RFC2385 [10]) may be used in addition
BGP's own authentication mechanisms. The error notification mechanism to BGP's own authentication mechanisms. The error notification
used in BGP assumes that the transport protocol supports a "graceful" mechanism used in BGP assumes that the transport protocol supports a
close, i.e., that all outstanding data will be delivered before the "graceful" close, i.e., that all outstanding data will be delivered
connection is closed. before the connection is closed.
To: To:
BGP uses TCP [RFC793] as its transport protocol. This eliminates the BGP uses TCP [RFC793] as its transport protocol. This eliminates the
need to implement explicit update fragmentation, retransmission, need to implement explicit update fragmentation, retransmission,
acknowledgment, and sequencing. BGP listens on TCP port 179. Any acknowledgment, and sequencing. BGP listens on TCP port 179. Any
authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
used. The error notification mechanism used in BGP assumes that TCP used. The error notification mechanism used in BGP assumes that TCP
supports a "graceful" close, i.e., that all outstanding data will be supports a "graceful" close, i.e., that all outstanding data will be
delivered before the connection is closed. delivered before the connection is closed.
3) Update the message header format section: 3) Update the message header format section:
From: From:
Marker: Marker:
This 16-octet field contains a value that the receiver of the This 16-octet field contains a value that the receiver of the message
message can predict. If the Type of the message is OPEN, or if can predict. If the Type of the message is OPEN, or if the OPEN
the OPEN message carries no Authentication Information (as an message carries no Authentication Information (as an Optional
Optional Parameter), then the Marker must be all ones. Parameter), then the Marker must be all ones. Otherwise, the value
Otherwise, the value of the marker can be predicted by some a of the marker can be predicted by some a computation specified as
computation specified as part of the authentication mechanism part of the authentication mechanism (which is specified as part of
(which is specified as part of the Authentication Information) the Authentication Information) used. The Marker can be used to
used. The Marker can be used to detect loss of synchronization detect loss of synchronization between a pair of BGP peers, and to
between a pair of BGP peers, and to authenticate incoming BGP authenticate incoming BGP messages.
messages.
To: To:
Marker: Marker:
This 16-octet field is included for compatibility; it must be This 16-octet field is included for compatibility; it must be set to
set to all ones. all ones.
4) Update the Message Header error handling section: 4) Update the Message Header error handling section:
In section 6.1 (Message Header error handling), second paragraph In section 6.1 (Message Header error handling), second paragraph
From: From:
The expected value of the Marker field of the message header is all The expected value of the Marker field of the message header is all
ones if the message type is OPEN. The expected value of the Marker ones if the message type is OPEN. The expected value of the Marker
field for all other types of BGP messages determined based on the field for all other types of BGP messages determined based on the
presence of the Authentication Information Optional Parameter in the presence of the Authentication Information Optional Parameter in the
BGP OPEN message and the actual authentication mechanism (if the BGP OPEN message and the actual authentication mechanism (if the
Authentication Information in the BGP OPEN message is present). If Authentication Information in the BGP OPEN message is present). If
the Marker field of the message header is not the expected one, then the Marker field of the message header is not the expected one, then
a synchronization error has occurred and the Error Subcode is set to a synchronization error has occurred and the Error Subcode is set to
Connection Not Synchronized. Connection Not Synchronized.
To: To:
The expected value of the Marker field of the message header is all The expected value of the Marker field of the message header is all
ones. If the Marker field of the message header is not as expected, ones. If the Marker field of the message header is not as expected,
then a synchronization error has occurred and the Error Subcode is then a synchronization error has occurred and the Error Subcode is
set to Connection Not Synchronized. set to Connection Not Synchronized.
5) Remove a paragraph from the OPEN message error handling section 5) Remove a paragraph from the OPEN message error handling section
(section 6.2): (section 6.2):
If the OPEN message carries Authentication Information (as an If the OPEN message carries Authentication Information (as an
Optional Parameter), then the corresponding authentication procedure Optional Parameter), then the corresponding authentication procedure
is invoked. If the authentication procedure (based on Authentication is invoked. If the authentication procedure (based on Authentication
Code and Authentication Data) fails, then the Error Subcode is set to Code and Authentication Data) fails, then the Error Subcode is set to
skipping to change at page 88, line 7 skipping to change at page 19, line 3337
To: To:
This document defines the following Optional Parameters: This document defines the following Optional Parameters:
a) Optional parameter type 1, Authentication Information, has been a) Optional parameter type 1, Authentication Information, has been
deprecated. deprecated.
We are at consensus with these changes. We are at consensus with these changes.
2.63 Clarify MED Removal Text 2.63. Clarify MED Removal Text
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Modify text to clear up MED removal behavior. Text is at Summary: Modify text to clear up MED removal behavior. Text is at
the end of the discussion. the end of the discussion.
Discussion: Discussion:
This discussion began when Jonathan posted a question to the list: This discussion began when Jonathan posted a question to the list:
skipping to change at page 88, line 37 skipping to change at page 19, line 3367
Juniper??? Juniper???
Other code??? Other code???
Change to "SHOULD"??? Change to "SHOULD"???
Enke responded that: Enke responded that:
As the MED value is treated as zero when the MED attribute is As the MED value is treated as zero when the MED attribute is
missing, removing the MED attribute is really equivalent to setting missing, removing the MED attribute is really equivalent to setting
the value to zero. Based on this logic, one can argue that "MED the value to zero. Based on this logic, one can argue that "MED
removal" is supported by multiple vendors. removal" is supported by multiple vendors.
However, I do see that the current text can be consolidated and However, I do see that the current text can be consolidated and
cleaned up: cleaned up:
------------------------ ------------------------
5.1.4 MULTI_EXIT_DISC 5.1.4 MULTI_EXIT_DISC
... ...
A BGP speaker MUST IMPLEMENT a mechanism based on local configuration A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
which allows the MULTI_EXIT_DISC attribute to be removed from a which allows the MULTI_EXIT_DISC attribute to be removed from a
route. This MAY be done prior to determining the degree of preference route. This MAY be done prior to determining the degree of
of the route and performing route selection (decision process phases preference of the route and performing route selection (decision
1 and 2). process phases 1 and 2).
An implementation MAY also (based on local configuration) alter the An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over an external value of the MULTI_EXIT_DISC attribute received over an external
link. If it does so, it shall do so prior to determining the degree link. If it does so, it shall do so prior to determining the degree
of preference of the route and performing route selection (decision of preference of the route and performing route selection (decision
process phases 1 and 2). process phases 1 and 2).
------------------------- -------------------------
How about this: How about this:
A BGP speaker MUST implement a mechanism based on local configuration A BGP speaker MUST implement a mechanism based on local configuration
which allows the value of MULTI_EXIT_DISC attribute of a received which allows the value of MULTI_EXIT_DISC attribute of a received
route to be altered. This shall be done prior to determining the route to be altered. This shall be done prior to determining the
degree of preference of the route and performing route selection degree of preference of the route and performing route selection
(decision process phases 1 and 2). (decision process phases 1 and 2).
-------------------------- --------------------------
In responding to a question, Enke also added: In responding to a question, Enke also added:
> Humm. I thought with a missing MED it was preferable to be treated > Humm. I thought with a missing MED it was preferable to be treated
> as worst not as 0. > as worst not as 0.
It was changed a long time ago. Please see the following text in It was changed a long time ago. Please see the following text in
Sect. 9.1.2.2 of the draft: Sect. 9.1.2.2 of the draft:
In the pseudo-code above, MED(n) is a function which returns the In the pseudo-code above, MED(n) is a function which returns the
value of route n's MULTI_EXIT_DISC attribute. If route n has no value of route n's MULTI_EXIT_DISC attribute. If route n has no
MULTI_EXIT_DISC attribute, the function returns the lowest possible MULTI_EXIT_DISC attribute, the function returns the lowest possible
MULTI_EXIT_DISC value, i.e. 0. MULTI_EXIT_DISC value, i.e. 0.
Curtis replied to Enke: Curtis replied to Enke:
If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a
knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should
change the spec to say that MED(n) returns the largest value possible change the spec to say that MED(n) returns the largest value possible
is MULTI_EXIT_DISC is missing since this has better loop suppression is MULTI_EXIT_DISC is missing since this has better loop suppression
behavior if the placement of MULTI_EXIT_DISC removal is moved in its behavior if the placement of MULTI_EXIT_DISC removal is moved in its
skipping to change at page 90, line 16 skipping to change at page 19, line 3444
remain loop free and so its hard to declare them out of scope, unless remain loop free and so its hard to declare them out of scope, unless
we forbid changing MULTI_EXIT_DISC and just allow it to be removed we forbid changing MULTI_EXIT_DISC and just allow it to be removed
(which does not reflect current practice). (which does not reflect current practice).
Curtis also added: Curtis also added:
The other issue was MED handling. In "5.1.4 MULTI_EXIT_DISC": The other issue was MED handling. In "5.1.4 MULTI_EXIT_DISC":
A BGP speaker MUST IMPLEMENT a mechanism based on local configuration A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
which allows the MULTI_EXIT_DISC attribute to be removed from a which allows the MULTI_EXIT_DISC attribute to be removed from a
route. This MAY be done prior to determining the degree of preference route. This MAY be done prior to determining the degree of
of the route and performing route selection (decision process phases preference of the route and performing route selection (decision
1 and 2). process phases 1 and 2).
An implementation MAY also (based on local configuration) alter the An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over an external value of the MULTI_EXIT_DISC attribute received over an external
link. If it does so, it shall do so prior to determining the degree link. If it does so, it shall do so prior to determining the degree
of preference of the route and performing route selection (decision of preference of the route and performing route selection (decision
process phases 1 and 2). process phases 1 and 2).
This doesn't sufficiently address the issue. This doesn't sufficiently address the issue.
The MED step in the decision process is (in 9.1.2.2): The MED step in the decision process is (in 9.1.2.2):
c) Remove from consideration routes with less-preferred c) Remove from consideration routes with less-preferred
MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
between routes learned from the same neighboring AS. Routes which do between routes learned from the same neighboring AS. Routes which do
not have the MULTI_EXIT_DISC attribute are considered to have the not have the MULTI_EXIT_DISC attribute are considered to have the
lowest possible MULTI_EXIT_DISC value. lowest possible MULTI_EXIT_DISC value.
This is also described in the following procedure: This is also described in the following procedure:
for m = all routes still under consideration for m = all routes still under consideration
for n = all routes still under consideration for n = all routes still under consideration
if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
remove route m from consideration remove route m from consideration
In the pseudo-code above, MED(n) is a function which returns the In the pseudo-code above, MED(n) is a function which returns the
value of route n's MULTI_EXIT_DISC attribute. If route n has no value of route n's MULTI_EXIT_DISC attribute. If route n has no
MULTI_EXIT_DISC attribute, the function returns the lowest possible MULTI_EXIT_DISC attribute, the function returns the lowest possible
MULTI_EXIT_DISC value, i.e. 0. MULTI_EXIT_DISC value, i.e. 0.
Similarly, neighborAS(n) is a function which returns the neighbor AS Similarly, neighborAS(n) is a function which returns the neighbor AS
from which the route was received. from which the route was received.
The problem is that a route loop can be formed. The problem is that a route loop can be formed.
To avoid the route loop, two suggestions were made (2-3 years ago and To avoid the route loop, two suggestions were made (2-3 years ago and
nothing was done). One was to make MED(n) return infinity if there nothing was done). One was to make MED(n) return infinity if there
skipping to change at page 91, line 25 skipping to change at page 19, line 3501
this. This implies that you MAY also remove after route selection, this. This implies that you MAY also remove after route selection,
in which case field experience indicates you WILL get burned (unless in which case field experience indicates you WILL get burned (unless
you know about the caveat above). Initially this came up as an you know about the caveat above). Initially this came up as an
interoperability issue but later it was proven (in the field) that a interoperability issue but later it was proven (in the field) that a
Cisco and another Cisco could form a route loop until Cisco made this Cisco and another Cisco could form a route loop until Cisco made this
change. change.
Additional wording is needed either in 5.1.4 or in 9.1.2.2. I Additional wording is needed either in 5.1.4 or in 9.1.2.2. I
suggest we put a forward reference in 5.1.4: suggest we put a forward reference in 5.1.4:
[...]. This MAY be done prior to determining the degree of preference [...]. This MAY be done prior to determining the degree of
of the route and performing route selection (decision process phases preference of the route and performing route selection (decision
1 and 2). See section 9.1.2.2 for necessary restricts on this. process phases 1 and 2). See section 9.1.2.2 for necessary restricts
on this.
Then in 9.1.2.2 add a clarification to the neighborAS(n) function and Then in 9.1.2.2 add a clarification to the neighborAS(n) function and
add to the existing text. add to the existing text.
Similarly, neighborAS(n) is a function which returns the neighbor AS Similarly, neighborAS(n) is a function which returns the neighbor AS
from which the route was received. If the route is learned via IBGP, from which the route was received. If the route is learned via IBGP,
it is the neighbor AS from which the other IBGP speaker learned the it is the neighbor AS from which the other IBGP speaker learned the
route, not the internal AS. route, not the internal AS.
If a MULTI_EXIT_DISC attribute is removed before redistributing a If a MULTI_EXIT_DISC attribute is removed before redistributing a
skipping to change at page 92, line 28 skipping to change at page 19, line 3554
loaded provider interconnects. loaded provider interconnects.
[Aside: Having a missing MULTI_EXIT_DISC default to infinity would do [Aside: Having a missing MULTI_EXIT_DISC default to infinity would do
exactly what the ISPs want it to do in the first place and be a lot exactly what the ISPs want it to do in the first place and be a lot
easier to explain but we didn't fix that 2-3 years ago when the issue easier to explain but we didn't fix that 2-3 years ago when the issue
came up even though we had WG consensus that it was the right thing came up even though we had WG consensus that it was the right thing
to do. The authors didn't act on it at the time (because Cisco to do. The authors didn't act on it at the time (because Cisco
didn't do it that way and the authors preferred to sit on the draft). didn't do it that way and the authors preferred to sit on the draft).
At this point we might as well adequately document what we ended up At this point we might as well adequately document what we ended up
with.... End of soap box. I don't take myself all that seriously so with.... End of soap box. I don't take myself all that seriously so
others shouldn't either. :-)] others shouldn't either. :-)]
After some more discussion on this, we have this text: After some more discussion on this, we have this text:
In 5.1.4 replace: In 5.1.4 replace:
An implementation MAY also (based on local configuration) alter the An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over EBGP. If it value of the MULTI_EXIT_DISC attribute received over EBGP. If it
does so, it shall do so prior to determining the degree of preference does so, it shall do so prior to determining the degree of preference
of the route and performing route selection (decision process phases of the route and performing route selection (decision process phases
1 and 2). 1 and 2).
with: with:
An implementation MAY also (based on local configuration) alter the An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY
be done prior to determining the degree of preference of the route be done prior to determining the degree of preference of the route
and performing route selection (decision process phases 1 and 2). See and performing route selection (decision process phases 1 and 2).
section 9.1.2.2 for necessary restricts on this. See section 9.1.2.2 for necessary restricts on this.
In 9.1.2.2 replace: In 9.1.2.2 replace:
Similarly, neighborAS(n) is a function which returns the neighbor AS Similarly, neighborAS(n) is a function which returns the neighbor AS
from which the route was received. from which the route was received.
with: with:
Similarly, neighborAS(n) is a function which returns the neighbor AS Similarly, neighborAS(n) is a function which returns the neighbor AS
from which the route was received. If the route is learned via IBGP, from which the route was received. If the route is learned via IBGP,
and the other IBGP speaker didn't originate the route, it is the and the other IBGP speaker didn't originate the route, it is the
neighbor AS from which the other IBGP speaker learned the route. If neighbor AS from which the other IBGP speaker learned the route. If
the route is learned via IBGP, and the other IBGP speaker originated the route is learned via IBGP, and the other IBGP speaker originated
the route, it is the local AS. the route, it is the local AS.
If a MULTI_EXIT_DISC attribute is removed before re-advertising a If a MULTI_EXIT_DISC attribute is removed before re-advertising a
route into IBGP, the MULTI_EXIT_DISC attribute may only be considered route into IBGP, the MULTI_EXIT_DISC attribute may only be considered
in the comparison of EBGP learned routes, then removed, then the in the comparison of EBGP learned routes, then removed, then the
remaining EBGP learned route may be compared to the remaining IBGP remaining EBGP learned route may be compared to the remaining IBGP
learned routes, without considering the MULTI_EXIT_DISC attribute for learned routes, without considering the MULTI_EXIT_DISC attribute for
those EBGP learned routes whose MULTI_EXIT_DISC will be dropped those EBGP learned routes whose MULTI_EXIT_DISC will be dropped
before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP before advertising to IBGP. Including the MULTI_EXIT_DISC of an EBGP
learned route in the comparison with an IBGP learned route, then learned route in the comparison with an IBGP learned route, then
dropping the MULTI_EXIT_DISC and advertising the route has been dropping the MULTI_EXIT_DISC and advertising the route has been
proven to cause route loops. proven to cause route loops.
There have been no objections to this, so we are at consensus. There have been no objections to this, so we are at consensus.
2.64 MED for Originated Routes 2.64. MED for Originated Routes
Status: Consensus Status: Consensus
Change: No Change: No
Summary: The consensus is that there is not need to specify default Summary: The consensus is that there is not need to specify default
values for MED in the base draft. values for MED in the base draft.
Discussion: Discussion:
This issue began when it was pointed out that we do not specify the This issue began when it was pointed out that we do not specify the
default values for MED in the base draft. default values for MED in the base draft.
There were a variety of responses, but the consensus is that since There were a variety of responses, but the consensus is that since
this is not relevant for interoperability, this does not need to be this is not relevant for interoperability, this does not need to be
in the base spec. in the base spec.
2.65 Rules for Aggregating with MED and NEXT_HOP 2.65. Rules for Aggregating with MED and NEXT_HOP
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Clear up the text on aggregating with a MED. See the Summary: Clear up the text on aggregating with a MED. See the
discussion for the text. discussion for the text.
Discussion: Discussion:
There is a proposal to relax this statement: There is a proposal to relax this statement:
skipping to change at page 94, line 26 skipping to change at page 19, line 3649
Routes that have the following attributes shall not be aggregated Routes that have the following attributes shall not be aggregated
unless the corresponding attributes of each route are identical: unless the corresponding attributes of each route are identical:
MULTI_EXIT_DISC, NEXT_HOP. MULTI_EXIT_DISC, NEXT_HOP.
If the aggregation occurs as part of the update process, routes with If the aggregation occurs as part of the update process, routes with
different NEXT_HOP values can be aggregated when announced through an different NEXT_HOP values can be aggregated when announced through an
external BGP session. external BGP session.
Path attributes that have different type codes can not be aggregated Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated, together. Path attributes of the same type code may be aggregated,
according to the following rules: according to the following rules:
with: with:
Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be
aggregated. aggregated.
Path attributes that have different type codes can not be aggregated Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated, together. Path attributes of the same type code may be aggregated,
according to the following rules: according to the following rules:
NEXT_HOP: When aggregating routes that have different NEXT_HOP NEXT_HOP: When aggregating routes that have different NEXT_HOP
attribute, the NEXT_HOP attribute of the aggregated route SHALL attribute, the NEXT_HOP attribute of the aggregated route SHALL
identify an interface on the router that performs the aggregation. identify an interface on the router that performs the aggregation.
This met with agreement. This met with agreement.
Dimitry asked if the "Routes that have different MULTI_EXIT_DESC Dimitry asked if the "Routes that have different MULTI_EXIT_DESC
attribute SHALL NOT be aggregated." sentence was unnecessary since it attribute SHALL NOT be aggregated." sentence was unnecessary since it
should be a matter of local policy. Jeff replied that it has been should be a matter of local policy. Jeff replied that it has been
mentioned that removing this stipulation can cause routing loops. mentioned that removing this stipulation can cause routing loops.
We are at consensus with this issue. We are at consensus with this issue.
2.66 Complex AS Path Aggregating 2.66. Complex AS Path Aggregating
Status: Consensus Status: Consensus
Change: No Change: No
Summary: Since we have two implementations of this method, section Summary: Since we have two implementations of this method, section
6.8 stays in the specification. 6.8 stays in the specification.
Discussion: Discussion:
Jonathan opened this discussion with: Jonathan opened this discussion with:
The part in the draft about complex AS path aggregation could/should The part in the draft about complex AS path aggregation could/should
skipping to change at page 95, line 30 skipping to change at page 19, line 3702
3 4 6 5 3 4 6 5
and and
5 6 7 8 5 6 7 8
then then
1 2 {3 4 5 6} 7 8 1 2 {3 4 5 6} 7 8
...would be OK
...would be OK
AFAIK, all implementations aggregate by either: (2nd)putting ONLY the AFAIK, all implementations aggregate by either: (2nd)putting ONLY the
local AS in the path (and setting the atomic) OR (3rd)by creating 1 local AS in the path (and setting the atomic) OR (3rd)by creating 1
giant set and adding the local AS as a seq. giant set and adding the local AS as a seq.
So he proposed we remove this to reflect current code. So he proposed we remove this to reflect current code.
Jeff replied that there is absolutely nothing wrong with doing Jeff replied that there is absolutely nothing wrong with doing
complex aggregation, and there is no reason to remove this from the complex aggregation, and there is no reason to remove this from the
specification. specification.
Yakov responded that: Yakov responded that:
Jonathan is certainly correct that the spec has to reflect current Jonathan is certainly correct that the spec has to reflect current
code. Therefore, unless there are at least two (interoperable) code. Therefore, unless there are at least two (interoperable)
implementations that implement the algorithm described in "6.8 implementations that implement the algorithm described in "6.8
Complex AS_PATH aggregation", this section has to be removed (this is Complex AS_PATH aggregation", this section has to be removed (this is
irrespective of whether there is something wrong, or nothing wrong irrespective of whether there is something wrong, or nothing wrong
with complex aggregation). With this in mind, if you implement this with complex aggregation). With this in mind, if you implement this
algorithm please speak up within a week. If within a week we algorithm please speak up within a week. If within a week we
wouldn't know that there are at least two implementations the section wouldn't know that there are at least two implementations the section
will be removed. And likewise, if we hear that there are at least two will be removed. And likewise, if we hear that there are at least
implementations, the section will stay. two implementations, the section will stay.
Jeff replied: Jeff replied:
I am also fine with removing it. I just don't think its necessary, I am also fine with removing it. I just don't think its necessary,
especially if One Of These Days someone decides that running policy especially if One Of These Days someone decides that running policy
based on as-adjacencies would be a Nice Thing and fixes their based on as-adjacencies would be a Nice Thing and fixes their
implementation to support "complex" aggregation of paths. implementation to support "complex" aggregation of paths.
That said, I am aware of no one who implements this. That said, I am aware of no one who implements this.
skipping to change at page 96, line 47 skipping to change at page 19, line 3766
So we will wait a week from 10/17 to see if anyone chimes in. So we will wait a week from 10/17 to see if anyone chimes in.
Siva responded that they have implemented this functionality. So we Siva responded that they have implemented this functionality. So we
need one more...Ben responded that they support this at Marconi as need one more...Ben responded that they support this at Marconi as
well. well.
So we have two implementations, the section stays in the spec. We So we have two implementations, the section stays in the spec. We
are at consensus with this issue. are at consensus with this issue.
2.67 Counting AS_SET/AS_CONFED_* 2.67. Counting AS_SET/AS_CONFED_*
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to
the BGP Confederations document. Update the base draft to reflect the BGP Confederations document. Update the base draft to reflect
this by changing section 9.1.2.2. Specific text is at the end of the this by changing section 9.1.2.2. Specific text is at the end of the
discussion. discussion.
Discussion: Discussion:
Jonathan brought up some questions on how current implementations Jonathan brought up some questions on how current implementations
count AS_SET and AS_CONFED_* count AS_SET and AS_CONFED_*
There were a variety of responses to this, answering his questions. There were a variety of responses to this, answering his questions.
Curtis pointed out that this behavior is covered in: Curtis pointed out that this behavior is covered in:
That's in 9.1.2.2: That's in 9.1.2.2:
a) Remove from consideration all routes which are not tied for having a) Remove from consideration all routes which are not tied for having
the smallest number of AS numbers present in their AS_PATH the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts as attributes. Note, that when counting this number, an AS_SET counts
1, no matter how many ASs are in the set, and that, if the as 1, no matter how many ASs are in the set, and that, if the
implementation supports [13], then AS numbers present in segments of implementation supports [13], then AS numbers present in segments of
type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the
count of AS numbers present in the AS_PATH. count of AS numbers present in the AS_PATH.
Jonathan replied that this might be at odds with what Juniper does, Jonathan replied that this might be at odds with what Juniper does,
although he was unsure, and asked for clarification. although he was unsure, and asked for clarification.
This was discussed in the "New Issue AS path" thread. This was discussed in the "New Issue AS path" thread.
Yakov proposed that: Yakov proposed that:
The issue of route selection in the present of confederations belongs The issue of route selection in the present of confederations belongs
*not* to the base spec, but to the spec that describes BGP Confeds. *not* to the base spec, but to the spec that describes BGP Confeds.
With this in mind I would suggest to change in 9.1.2.2 from With this in mind I would suggest to change in 9.1.2.2 from
a) Remove from consideration all routes which are not tied for having a) Remove from consideration all routes which are not tied for having
the smallest number of AS numbers present in their AS_PATH the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts as attributes. Note, that when counting this number, an AS_SET counts
1, no matter how many ASs are in the set, and that, if the as 1, no matter how many ASs are in the set, and that, if the
implementation supports [13], then AS numbers present in segments of implementation supports [13], then AS numbers present in segments of
type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in the
count of AS numbers present in the AS_PATH. count of AS numbers present in the AS_PATH.
to to
a) Remove from consideration all routes which are not tied for having a) Remove from consideration all routes which are not tied for having
the smallest number of AS numbers present in their AS_PATH the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts as attributes. Note, that when counting this number, an AS_SET counts
1, no matter how many ASs are in the set. as 1, no matter how many ASs are in the set.
and ask the authors of BGP Confeds to update their document to cover and ask the authors of BGP Confeds to update their document to cover
how the presence of confeds impact route selection. how the presence of confeds impact route selection.
This met with agreement, this issue is at consensus. This met with agreement, this issue is at consensus.
2.68 Outbound Loop Detection 2.68. Outbound Loop Detection
Status: Consensus Status: Consensus
Change: No Change: No
Summary: The consensus is, that while this may be a useful technique, Summary: The consensus is, that while this may be a useful technique,
it would break existing methods, and is otherwise out-of-scope for it would break existing methods, and is otherwise out-of-scope for
the base draft. It was suggested that this could be addressed in the the base draft. It was suggested that this could be addressed in the
update to RFC1772. update to RFC1772.
Discussion: Discussion:
Jonathan brought up that: Jonathan brought up that:
This paper (thanks Jeff) This paper (thanks Jeff) http://www.research.microsoft.com/scripts/
http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR- pubs/view.asp?TR_ID=MSR-TR-2000-08 indicates that it is better to do
TR-2000-08 indicates that it is better to do the loop detection the loop detection outbound as well inbound. The current draft
outbound as well inbound. The current draft indicates that it only indicates that it only needs to be done inbound. IOS does it inbound
needs to be done inbound. IOS does it inbound as well as outbound. as well as outbound. GateD/Juniper does it (did it ???) only
GateD/Juniper does it (did it ???) only inbound. inbound.
So I propose we add: "An implementation MAY choose to not advertise So I propose we add: "An implementation MAY choose to not advertise
routes to EBGP peers if these routes contain the AS of that peer in routes to EBGP peers if these routes contain the AS of that peer in
the AS path." after: "If the autonomous system number appears in the the AS path." after: "If the autonomous system number appears in the
AS path the route may be stored in the Adj-RIB In, but unless the AS path the route may be stored in the Adj-RIB In, but unless the
router is configured to accept routes with its own AS in the AS path, router is configured to accept routes with its own AS in the AS path,
the route shall not be passed to the BGP Decision Process." the route shall not be passed to the BGP Decision Process."
*If there is at least one other implementation that does outbound *If there is at least one other implementation that does outbound
pruning/loop-detection.* pruning/loop-detection.*
Yakov pointed out that this is ONLY applicable to the base draft if Yakov pointed out that this is ONLY applicable to the base draft if
there are multiple implementations doing this. This issue will only there are multiple implementations doing this. This issue will only
be considered if these implementors come forward by 10/25/02. be considered if these implementors come forward by 10/25/02.
Otherwise the issue will be considered closed. Otherwise the issue will be considered closed.
Jeff replied that there was more at stake with this than if people Jeff replied that there was more at stake with this than if people
had implemented it: had implemented it:
My suggestion is that this can stay out of the base draft. While it My suggestion is that this can stay out of the base draft. While it
is true that this speeds up convergence (per the paper), it doesn't is true that this speeds up convergence (per the paper), it doesn't
affect interoperability. affect interoperability.
Also, adding this specifically removes the ability from several .in 4 Also, adding this specifically removes the ability from several
implementations to be able to bridge a partitioned AS by permitting implementations to be able to bridge a partitioned AS by permitting
loops. (I'm not going to argue whether this is a Good way to do loops. (I'm not going to argue whether this is a Good way to do
this, just that its done.) this, just that its done.)
Its also worth noting that one could produce the same resultant Its also worth noting that one could produce the same resultant
speed-up by detecting the loop on an outbound basis and *not* speed-up by detecting the loop on an outbound basis and *not*
applying the min*timers to the UPDATE. Thus, this would be a case applying the min*timers to the UPDATE. Thus, this would be a case of
of an advertisement of NLRI being treated the same, timer-wise, as an advertisement of NLRI being treated the same, timer-wise, as the
the advertisement of WD_NLRI. advertisement of WD_NLRI.
I would suggest moving this suggestion for outbound loop detection I would suggest moving this suggestion for outbound loop detection in
in one form or another to the 1772 replacement. one form or another to the 1772 replacement.
Yakov agreed with this. Yakov agreed with this.
2.69 Appendix A - Other Documents 2.69. Appendix A - Other Documents
Over the course of this discussion, a number of issues have been Over the course of this discussion, a number of issues have been
raised that the group though would be better dealt with in other raised that the group though would be better dealt with in other
documents. These additional documents, and their concomitant issues documents. These additional documents, and their concomitant issues
will be more fully addressed when the WG turns its focus to them. will be more fully addressed when the WG turns its focus to them.
These projects are: These projects are:
1) Update RFC 1772: Application of the Border Gateway Protocol in the 1) Update RFC 1772: Application of the Border Gateway Protocol in the
Internet. This will probably entail a complete rewrite. Internet. This will probably entail a complete rewrite.
2) Update Route Reflector (2796) and Confederation (3065) RFC's 2) Update Route Reflector (2796) and Confederation (3065) RFC's
regarding their impact on route selection. regarding their impact on route selection.
3) Write a new document covering BGP Multipath. 3) Write a new document covering BGP Multipath. .ne 4
3. The Issues from -18 to -19. 3. The Issues from -18 to -19
This section lists the issues discussed on the list from November This section lists the issues discussed on the list from November
2002 to late February 2003. 2002 to late February 2003.
3.1 Reference to RFC 1772 3.1. Reference to RFC 1772
Status: Consensus Status: Consensus
Change: No Change: No
Summary: Proposed changing RFC 1772 reference, since that document Summary: Proposed changing RFC 1772 reference, since that document
should be updated. should be updated.
Discussion: Discussion:
Jeff proposed that we reconsider referencing RFC 1772, since that Jeff proposed that we reconsider referencing RFC 1772, since that
document should be updated. document should be updated.
Yakov pointed out that this is a non-normative reference and can just Yakov pointed out that this is a non-normative reference and can just
be left as is. be left as is.
Jeff agreed that this wasn't a big deal. We are at consensus to Jeff agreed that this wasn't a big deal. We are at consensus to
leave things as they are. leave things as they are.
This was discussed in the "-18 last call comments" thread. This was discussed in the "-18 last call comments" thread.
3.2 MUST/SHOULD Capitalization 3.2. MUST/SHOULD Capitalization
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Capitalize MUST/SHOULD where appropriate. Summary: Capitalize MUST/SHOULD where appropriate.
Discussion: Discussion:
Jeff brought this up, and Yakov responded asking that he point out Jeff brought this up, and Yakov responded asking that he point out
specific instances where this is needed. Jeff said he would do so, specific instances where this is needed. Jeff said he would do so,
given some time. given some time.
skipping to change at page 100, line 30 skipping to change at page 19, line 3940
Jeff brought this up, and Yakov responded asking that he point out Jeff brought this up, and Yakov responded asking that he point out
specific instances where this is needed. Jeff said he would do so, specific instances where this is needed. Jeff said he would do so,
given some time. given some time.
Yakov later replied that this would be fixed in the -19 version. Yakov later replied that this would be fixed in the -19 version.
Jeff replied with a master diff showing the MUST/SHOULDs, for the Jeff replied with a master diff showing the MUST/SHOULDs, for the
entire document please see the beginning of the thread entitled: entire document please see the beginning of the thread entitled:
"Issues list, #2: MUST/SHOULD Capitalization" "Issues list, #2: MUST/SHOULD Capitalization"
This was discussed in the "18 last call comments" thread. This was This was discussed in the "18 last call comments" thread. This was
also brought up in the "proxy: comments on draft -18" thread. also brought up in the "proxy: comments on draft -18" thread.
3.3 Fix Update Error Subcode 7 -- accidently removed. 3.3. Fix Update Error Subcode 7 -- accidently removed
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add error subcode 7 back in, it looks like it was Summary: Add error subcode 7 back in, it looks like it was
inadvertently removed. Add deprecation text to Open Message Error inadvertently removed. Add deprecation text to Open Message Error
subcode 5. subcode 5.
Discussion: Discussion:
Jeff supplied: Jeff supplied:
Update message error subcode 7 is removed. Especially in -18, Update message error subcode 7 is removed. Especially in -18, it
it looks like an editing mistake based on where it would fall looks like an editing mistake based on where it would fall in the
in the editing.. editing..
Yakov mentioned that this is addressed in Appendix A. Yakov mentioned that this is addressed in Appendix A.
Jeff replied: Jeff replied:
What I would like to see is something like this: .in 4 What I would like to see is something like this:
6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 - 6 - Invalid ORIGIN Attribute 7 - [Deprecated - See Appendix A] 8 -
Invalid NEXT_HOP Attribute Invalid NEXT_HOP Attribute
As it stands, 7 lies on a page boundary and looks like it got As it stands, 7 lies on a page boundary and looks like it got clipped
clipped by the roff. by the roff.
Yakov agreed, and also said he would add similar text for Open Yakov agreed, and also said he would add similar text for Open
Message Error subcode 5. Message Error subcode 5.
This was discussed in the "18 last call comments" thread. This was discussed in the "18 last call comments" thread.
3.4 Section 5.1.4 - Editorial Comment 3.4. Section 5.1.4 - Editorial Comment
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Fix "restricts" to "RESTRICTIONS" Summary: Fix "restricts" to "RESTRICTIONS"
Discussion: Discussion:
Jeff proposed an editorial fix. This is agreed to. Jeff proposed an editorial fix. This is agreed to.
This was discussed in the "-18 last call comments" thread. This was discussed in the "-18 last call comments" thread.
3.5 Section 9.1 - Change "all peers" to "peers" 3.5. Section 9.1 - Change "all peers" to "peers"
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Section 9.1 - Change "all peers" to "peers" Summary: Section 9.1 - Change "all peers" to "peers"
Discussion: Discussion:
Jeff proposed: Jeff proposed:
9.1: The output of the Decision Process is the set of routes that .in 4 9.1: The output of the Decision Process is the set of routes
will be advertised to (delete all) peers; the selected routes will that will be advertised to (delete all) peers; the selected routes
be stored in the local speaker's Adj-RIB-Out according to policy. will be stored in the local speaker's Adj-RIB-Out according to
policy.
The previous wording implied that routes in the LocRib MUST be The previous wording implied that routes in the LocRib MUST be placed
placed in the adj-rib-out. in the adj-rib-out.
Yakov agreed, this fix will be in the next revision. Yakov agreed, this fix will be in the next revision.
This was discussed in the "-18 last call comments" thread. This was discussed in the "-18 last call comments" thread.
3.6 AS Loop Detection & Implicit Withdraws 3.6. AS Loop Detection & Implicit Withdraws
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Update the text to reflect the AS Loop detection should be Summary: Update the text to reflect the AS Loop detection should be
done in the BGP decision process. done in the BGP decision process.
Discussion: Discussion:
John brought this up, and suggested: John brought this up, and suggested:
I have one further comment just in case it's not perfectly obvious .in 4 I have one further comment just in case it's not perfectly
to everyone, which is that "ignore the UPDATE" is not strictly the obvious to everyone, which is that "ignore the UPDATE" is not
action you take when receiving a looped update. Rather, you treat strictly the action you take when receiving a looped update. Rather,
it as an implicit withdraw, i.e. you process it as any other update you treat it as an implicit withdraw, i.e. you process it as any
but treat the contained NLRI as unfeasible. other update but treat the contained NLRI as unfeasible.
I was going to write that this is sufficiently clear from the spec, I was going to write that this is sufficiently clear from the spec,
but I regret to say that it isn't. Here is the fourth paragraph of but I regret to say that it isn't. Here is the fourth paragraph of
section 9: section 9:
The information carried by the AS_PATH attribute is checked for .in 8 The information carried by the AS_PATH attribute is checked for
AS loops. AS loop detection is done by scanning the full AS path AS loops. AS loop detection is done by scanning the full AS path (as
(as specified in the AS_PATH attribute), and checking that the specified in the AS_PATH attribute), and checking that the autonomous
autonomous system number of the local system does not appear in system number of the local system does not appear in the AS path. If
the AS path. If the autonomous system number appears in the AS the autonomous system number appears in the AS path the route may be
path the route may be stored in the Adj-RIB-In, but unless the stored in the Adj-RIB-In, but unless the router is configured to
router is configured to accept routes with its own autonomous accept routes with its own autonomous system in the AS path, the
system in the AS path, the route shall not be passed to the BGP route shall not be passed to the BGP Decision Process. Operations of
Decision Process. Operations of a router that is configured to a router that is configured to accept routes with its own autonomous
accept routes with its own autonomous system number in the AS system number in the AS path are outside the scope of this document.
path are outside the scope of this document.
I don't think this is quite right -- the decision process needs to .in 4 I don't think this is quite right -- the decision process needs
be run if the looped routes had previously been advertised feasibly to be run if the looped routes had previously been advertised
on the same session. This could be fixed by hacking the quoted feasibly on the same session. This could be fixed by hacking the
paragraph, but it seems more straightforward to do it by removing quoted paragraph, but it seems more straightforward to do it by
the quoted paragraph and making the fix in 9.1.2 Phase 2 instead. removing the quoted paragraph and making the fix in 9.1.2 Phase 2
This could be done by inserting the following between the third and instead. This could be done by inserting the following between the
fourth paragraphs of 9.1.2 Phase 2: third and fourth paragraphs of 9.1.2 Phase 2:
If the AS_PATH attribute of a BGP route contains an AS loop, the .in 8 If the AS_PATH attribute of a BGP route contains an AS loop,
BGP route should be excluded from the Phase 2 decision function. the BGP route should be excluded from the Phase 2 decision function.
AS loop detection is done by scanning the full AS path (as AS loop detection is done by scanning the full AS path (as specified
specified in the AS_PATH attribute), and checking that the in the AS_PATH attribute), and checking that the autonomous system
autonomous system number of the local system does not appear in number of the local system does not appear in the AS path.
the AS path. Operations of a router that is configured to Operations of a router that is configured to accept routes with its
accept routes with its own autonomous system number in the AS own autonomous system number in the AS path are outside the scope of
path are outside the scope of this document. this document.
Section 9.3, first bullet, also addresses this topic, but I don't .in 4 Section 9.3, first bullet, also addresses this topic, but I
think it's sufficient. don't think it's sufficient.
Yakov agreed that this was a change for the better and will include Yakov agreed that this was a change for the better and will include
this in the next revision. this in the next revision.
We are at consensus on this issue. We are at consensus on this issue.
This is discussed in the "-18 last call comments" thread. This is discussed in the "-18 last call comments" thread.
3.7 Standardize FSM Timer Descriptions 3.7. Standardize FSM Timer Descriptions
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Standardize the state descriptions on those listed in the Summary: Standardize the state descriptions on those listed in the
discussion section of this issue. discussion section of this issue.
Discussion: Discussion:
Tom proposed: Tom proposed:
I think a standard description would serve us better instead of .in 4 I think a standard description would serve us better instead of
using the following different ways (which I take all to refer to using the following different ways (which I take all to refer to the
the same entity): same entity):
delayBGP open timer delayBGP open timer BGP delay open timer BGP open delay timer delay
BGP delay open timer open timer BGP delay timer
BGP open delay timer
delay open timer
BGP delay timer
I suggest Open Delay timer (with those capitals) .in 4 I suggest Open Delay timer (with those capitals)
I believe that the corresponding flag is consistently referred to I believe that the corresponding flag is consistently referred to
(apart from the capitalization) as Delay Open flag (apart from the capitalization) as Delay Open flag
Yakov agreed with this suggestion, no one else disagreed, we are at Yakov agreed with this suggestion, no one else disagreed, we are at
consensus. consensus.
This was discussed in the "BGP18-FSM-terminology" thread. This was discussed in the "BGP18-FSM-terminology" thread.
3.8 FSM MIB enumerations 3.8. FSM MIB enumerations
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Move MIB references from the base spec into the MIB Summary: Move MIB references from the base spec into the MIB
document. document.
Discussion: Discussion:
Tom pointed out that: Tom pointed out that:
The FSM makes several references to putting values into MIB objects The FSM makes several references to putting values into MIB objects
and while some of the values are defined, eg FSM error or Hold Timer and while some of the values are defined, eg FSM error or Hold Timer
expired, I can find no definition of the following in any of the BGP expired, I can find no definition of the following in any of the BGP
documents, MIB or otherwise. documents, MIB or otherwise.
connect retry expired connect retry expired TCP disconnect administrative down collision
TCP disconnect detect closure Call Collision cease collision detected and dump
administrative down connection Administrative stop
collision detect closure
Call Collision cease
collision detected and dump connection
Administrative stop
I believe an implementation needs to be told these values somewhere I believe an implementation needs to be told these values somewhere
and that there should be a reference to that place in bgp18. and that there should be a reference to that place in bgp18.
Jeff replied that to make things easier, the MIB references will be Jeff replied that to make things easier, the MIB references will be
removed from the base spec, and into the MIB document. removed from the base spec, and into the MIB document.
This was discussed in the "WG Last Call FSM MIB enumeration" thread, This was discussed in the "WG Last Call FSM MIB enumeration" thread,
and the "bgp18 WG Last Call fsm MIB objects" thread. and the "bgp18 WG Last Call fsm MIB objects" thread.
3.9 Make "delete routes" language consistent 3.9. Make "delete routes" language consistent
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Replace a variety of wording with "deletes all routes Summary: Replace a variety of wording with "deletes all routes
associated with this connection,". associated with this connection,".
Discussion: Discussion:
Tom pointed out that we use a variety of language to say how we are Tom pointed out that we use a variety of language to say how we are
going to delete routes in the FSM. He proposed that we instead use: going to delete routes in the FSM. He proposed that we instead use:
- deletes all routes associated with this connection, - deletes all routes associated with this connection,
This met with agreement, and will be reflected in the next version. This met with agreement, and will be reflected in the next version.
This was discussed in the "bgp18 WG Last Call fsm delete action" This was discussed in the "bgp18 WG Last Call fsm delete action"
thread. thread.
3.10 Correct OpenSent and OpenConfirm delete wording 3.10. Correct OpenSent and OpenConfirm delete wording
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Remove delete wording from OpenSent and OpenConfirm states. Summary: Remove delete wording from OpenSent and OpenConfirm states.
Discussion: Discussion:
Venu asked why there was delete wording in the OpenSent and Venu asked why there was delete wording in the OpenSent and
OpenConfirm states when a BGP speaker cannot receive routes in these OpenConfirm states when a BGP speaker cannot receive routes in these
states. states.
Jeff acknowledged that this was an error. Yakov agreed to fix the Jeff acknowledged that this was an error. Yakov agreed to fix the
next version. next version.
This was discussed in the "bgp18 WG Last Call fsm delete action" This was discussed in the "bgp18 WG Last Call fsm delete action"
thread. thread.
3.11 Incorrect next state when the delay open timer expires. 3.11. Incorrect next state when the delay open timer expires
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Fix the next state. Summary: Fix the next state.
Discussion: Discussion:
Tom pointed out that: Tom pointed out that:
I believe that there is an incorrect next state when the delay open I believe that there is an incorrect next state when the delay open
timer expires [event 12] in the Active state. The next state should timer expires [event 12] in the Active state. The next state should
be OpenSent and not OpenConfirm. be OpenSent and not OpenConfirm.
OpenConfirm is for KeepAlive processing when Open messages have been OpenConfirm is for KeepAlive processing when Open messages have been
sent and received. sent and received.
OpenSent is for Open sent and not yet received. OpenSent is for Open sent and not yet received.
The corresponding section in Connect state I believe is correct. The corresponding section in Connect state I believe is correct.
Yakov agreed, and will fix this in the next revision. Yakov agreed, and will fix this in the next revision.
This was discussed in the "bgp18 WG Last Call fsm incorrect next This was discussed in the "bgp18 WG Last Call fsm incorrect next
state" state"
3.12 Entering OpenConfirm / Adding "Stop OpenDelay" action 3.12. Entering OpenConfirm / Adding "Stop OpenDelay" action
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add this text: Summary: Add this text:
Change 2 - Change 2 - Connect state event 17 (currently defined as going to
Connect state Active) event 9 (stays in Connect state)
event 17 (currently defined as going to Active)
event 9 (stays in Connect state)
new Text: new Text:
In response to the connect retry timer expires event [Event In response to the connect retry timer expires event [Event 9], the
9], the local system: local system: - drops the TCP connection, - restarts the connect
- drops the TCP connection, retry timer, - stops the Open Delay timer and resets the timer to
- restarts the connect retry timer, zero, - initiates a TCP connection to the other BGP peer, - continues
- stops the Open Delay timer and resets the timer to zero, to listen for a connection that may be initiated by the remote BGP
- initiates a TCP connection to the other BGP peer, peer, and - stays in Connect state.
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- stays in Connect state.
If the TCP connection fails [Event17], the local system: If the TCP connection fails [Event17], the local system: - restarts
- restarts the connect retry timer, the connect retry timer, - stops the Open Delay timer and resets
- stops the Open Delay timer and resets value to zero, value to zero, - continues to listen for a connection that may be
- continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active.
initiated by the remote BGP peer, and
- changes its state to Active.
Further discussion on Keepalives has been moved to issue 52. Further discussion on Keepalives has been moved to issue 52.
Discussion: Discussion:
This discussion began with Tom outlining these two points: This discussion began with Tom outlining these two points:
When the OpenConfirm state is entered from OpenSent with the receipt When the OpenConfirm state is entered from OpenSent with the receipt
of a valid open [Event 18], then a KeepAlive message is sent and the of a valid open [Event 18], then a KeepAlive message is sent and the
timer is started. timer is started.
When the OpenConfirm state is entered from Active or Connect on
receipt of a valid open [Event 19], no message is sent, no timer is
started.
I believe this inconsistency is an error and should be corrected by When the OpenConfirm state is entered from Active or Connect on
adding these two actions in those two places. receipt of a valid open [Event 19], no message is sent, no timer is
started. I believe this inconsistency is an error and should be
corrected by adding these two actions in those two places.
Sue replied: Sue replied:
Just to clarify this comment: Just to clarify this comment: Event 19 = valid open with delay timer
running
Event 19 = valid open with delay timer running
Active = 1) awaiting TCP connection, or Active = 1) awaiting TCP connection, or 2) TCP connection completed
2) TCP connection completed and awaiting the and awaiting the TCP connection with delay timer running
TCP connection with delay timer running
Case 1: - should not see Event 19 Case 1: - should not see Event 19 In transition from Active to Open
In transition from Active to Open Confirm, the connection Confirm, the connection must have a TCP connection completed. Case 1
must have a TCP connection completed. Case 1 does not does not have this occurring, so the transition must be avoided.
have this occurring, so the transition must be avoided.
Case 2: - should see Event 19 Case 2: - should see Event 19
- Open, Keepalive should be sent. - Open, Keepalive should be sent.
Previous text: (Action H from FSM document) Previous text: (Action H from FSM document)
If an Open is received with the BGP Delay Open timer running, If an Open is received with the BGP Delay Open timer running, [Event
[Event 19], the local system: 19], the local system: - clears the connect retry timer [cleared to
- clears the connect retry timer [cleared to zero), zero), - completes the BGP initialization, - stop and clears the BGP
- completes the BGP initialization, Open Delay timer, - Sends an Open Message, - sets the hold timer to a
- stop and clears the BGP Open Delay timer, large value (4 minutes), and - changes its state to an Open Confirm.
- Sends an Open Message,
- sets the hold timer to a large value (4 minutes), and
- changes its state to an Open Confirm.
New text: [a New Action - N-2 : N + BGP keepalive sent] New text: [a New Action - N-2 : N + BGP keepalive sent]
If an Open is received with the BGP Delay Open Timer running If an Open is received with the BGP Delay Open Timer running [Event
[Event 19], the local system: 19], the local system: - clear the connect retry timer [cleared to
- clear the connect retry timer [cleared to zero], zero], - completes the BGP initialization, - stops and clears the BGP
- completes the BGP initialization, Open Delay timer, - Send an Open message, - Sends a Keepalive
- stops and clears the BGP Open Delay timer, message, - If hold timer value is non-zero, - set keepalive timer -
- Send an Open message, hold timer reset to negotiated value else if hold timer is zero, -
- Sends a Keepalive message, reset the keepalive timer, and - reset the hold timer.
- If hold timer value is non-zero,
- set keepalive timer
- hold timer reset to negotiated value
else if hold timer is zero,
- reset the keepalive timer, and
- reset the hold timer.
- If the value of the autonomous system field is the - If the value of the autonomous system field is the same as the
same as the local Autonomous system number, set local Autonomous system number, set the connection status to a
the connection status to a internal connection; internal connection; otherwise it is "external".
otherwise it is "external".
Tom and Sue discussed the OpenDelay state, and recalled that this was Tom and Sue discussed the OpenDelay state, and recalled that this was
excluded a number of months ago as not reflecting current practice. excluded a number of months ago as not reflecting current practice.
By way of clarification, Sue added: By way of clarification, Sue added:
1) Agree, this can occur in the Active state as well as the 1) Agree, this can occur in the Active state as well as the Connect
Connect state. Will you accept the earlier text below state. Will you accept the earlier text below to be inserted both
to be inserted both places? places?
Background: Background:
The state machine for Event 19 is: The state machine for Event 19 is:
Idle Connect Active Open Open Estb Idle Connect Active Open Open Estb Sent Confirm
Sent Confirm ================================================ Event 19 | | | | | |
================================================ | next state |Idle | Open | Open | Open |Idle | Idle | | | confirm|
Event 19 | | | | | | | confirm| Confirm| | |
next state |Idle | Open | Open | Open |Idle | Idle | ================================================ action | V | N-2 |
| | confirm| confirm| Confirm| | | N-2 | N | E-1 | E | ================================================
================================================
action | V | N-2 | N-2 | N | E-1 | E |
================================================
Per the State Machine. Per the State Machine.
Action v - FSM Error Action v - FSM Error Action E - FSM Error, drop connection - etc,
Action E - FSM Error, drop connection - etc, drop routes drop routes Action E-1 - FSM Error, drop connection (lots of Action
Action E-1 - FSM Error, drop connection (lots of N-2 (text below) Action N (text below, without sending Open)
Action N-2 (text below)
Action N (text below, without sending Open)
2) Do you think that Event 19 is possible in the Open Sent state? 2) Do you think that Event 19 is possible in the Open Sent state?
Please answer this separately. Please answer this separately.
Tom replied that: Tom replied that:
1) yes I think the same text in both Active and Connect states is a .in 4 1) yes I think the same text in both Active and Connect states
good resolution is a good resolution
2) complicated. As the fsm text stands, Event 19, along with a 2) complicated. As the fsm text stands, Event 19, along with a host
host of others, takes us back from Open Sent to Idle (I assume on of others, takes us back from Open Sent to Idle (I assume on the
the grounds this is an error condition) which seems very reasonable. grounds this is an error condition) which seems very reasonable.
But ...in quite a few places, such as Connect state events 2, But ...in quite a few places, such as Connect state events 2,
7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer
when going to Idle or Active so we could then go from eg Idle with when going to Idle or Active so we could then go from eg Idle with
Manual start [event 1] to Connect to Open Sent all before the Manual start [event 1] to Connect to Open Sent all before the
OpenDelay timer expires in which case event 19 can occur validly in OpenDelay timer expires in which case event 19 can occur validly in
Open Sent - obscure but possible. (This is also true with Active Open Sent - obscure but possible. (This is also true with Active
state and events 2, 17 and the default list at the end). state and events 2, 17 and the default list at the end).
But I think this is an error, and that when exiting Connect state or But I think this is an error, and that when exiting Connect state or
Active state as listed above, we should have an additional action to Active state as listed above, we should have an additional action to
stop the OpenDelay timer in which case event 19 in Open Sent becomes stop the OpenDelay timer in which case event 19 in Open Sent becomes
an error condition (again). an error condition (again).
But but but as ever, I cannot speak with authority for But but but as ever, I cannot speak with authority for
implementations and so if implementations do not stop the OpenDelay implementations and so if implementations do not stop the OpenDelay
timer when exiting as above, then Event 19 is valid in Open Sent timer when exiting as above, then Event 19 is valid in Open Sent
state - obscure but possible (again). state - obscure but possible (again).
My wish is to add the extra action, stop OpenDelay timer, for the My wish is to add the extra action, stop OpenDelay timer, for the
events listed above in Active and Connect states in the expectation events listed above in Active and Connect states in the expectation
that that is what people have or should have implemented. that that is what people have or should have implemented.
Tom added a response to Sue after some other threads have been Tom added a response to Sue after some other threads have been
discussed: discussed: .in 4
You asked if event 19 (Open with OpenDelay timer running) was
possible in OpenSent state; I gave a lengthy reply (below) to the
effect yes it could because the OpenDelay timer did not always get
stopped but the timer should be stopped in which case the event
would not happen.
Reading your responses to Siva , I see you include stopping the Open You asked if event 19 (Open with OpenDelay timer running) was
Delay timer in the action 'release all BGP resources' when going to possible in OpenSent state; I gave a lengthy reply (below) to the
Idle (which I missed seeing earlier in the year). effect yes it could because the OpenDelay timer did not always get
stopped but the timer should be stopped in which case the event would
not happen.
That eliminates most but not all of the possibilities I mentioned. Reading your responses to Siva , I see you include stopping the Open
I now believe we would need to add the action 'stop OpenDelay timer' Delay timer in the action 'release all BGP resources' when going to
for Idle (which I missed seeing earlier in the year).
Connect state That eliminates most but not all of the possibilities I mentioned. I
event 17 (currently defined as going to Active) now believe we would need to add the action 'stop OpenDelay timer'
event 9 (stays in Connect state) for Connect state event 17 (currently defined as going to Active)
event 9 (stays in Connect state)
in order to stop event 19 in Open Sent in order to stop event 19 in Open Sent
Sue replied that, she thought this was at consensus, and provided the Sue replied that, she thought this was at consensus, and provided the
new text, which is: new text, which is:
Change 1: new text Change 1: new text
Active state - event 19
If an Open is received with the Open Delay timer is
running [Event 19], the local system
- clears the connect retry timer (cleared to zero),
- stops and clears the Open Delay timer
- completes the BGP initialization,
- stops and clears the Open Delay timer
- sends an OPEN message,
- send a Keepalive message,
- if the hold timer value is non-zero,
- starts the keepalive timer to initial value,
- resets the hold timer to the negotiated value,
else if the hold timer is zero
- resets the keepalive timer (set to zero),
- resets the hold timer to zero.
- changes its state to OpenConfirm. Active state - event 19
If the value of the autonomous system field is the same as the If an Open is received with the Open Delay timer is running [Event
local Autonomo