idnits 2.17.1 draft-chakrabarti-idr-rfc4893-mod-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2008) is 5879 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4893 (ref. '1') (Obsoleted by RFC 6793) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Domain Routing S. Chakrabarti 3 Internet-Draft IP Infusion - An Access Company 4 Intended status: Standards Track March 2008 5 Expires: September 2, 2008 7 A proposal for modification of BGP 4-octet AS number usage 8 draft-chakrabarti-idr-rfc4893-mod-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 2, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 RFC 4893 defines BGP support for four-octet AS number space. This 42 document proposes clarification texts for RFC 4893 for clear 43 understanding of the transition behavior between existing 44 implementations with two-octet AS numbers and the new BGP 45 implementations with four-octet AS numbers. This document also 46 proposes an addition of notification message and clearly defines the 47 processing of "My AS Number" field in the BGP OPEN message for better 48 interoperability during the transition phase of two-octet and four- 49 octet compliant BGP speakers. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Clarification issue-I . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. Proposal for new text . . . . . . . . . . . . . . . . . . . 4 58 5. Clarification - issue-2 . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Proposal for new text . . . . . . . . . . . . . . . . . . . 5 60 6. Clarification - issue-3 . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Proposal for change in protocol . . . . . . . . . . . . . . 6 62 7. Calrification issue-4 . . . . . . . . . . . . . . . . . . . . . 6 63 8. Proposal for a NOTIFICATION message . . . . . . . . . . . . . . 6 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 11. Normative References . . . . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Intellectual Property and Copyright Statements . . . . . . . . . . 8 70 1. Requirements notation 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [3]. 76 2. Introduction 78 RFC 4893[1] defines the extensions to BGP in order to use 4-byte 79 autonomous system (AS) number and it also describes the behavior of 80 BGP speakers with 4-byte AS numbers and the existing BGP speakers 81 with 2-byte AS numbers for ease of transitions. However, the 82 specification requires more clarity in handling the AS numbers in 83 OPEN and UPDATE messages between the 2-byte AS number speakers and 84 4-byte AS number speakers. Without the clear understanding of 85 handling of these messages the existing and new implementations of 86 BGP speakers may fail to interoperate or may degrade routing services 87 over the Internet. 89 This document is initiated based on some questions raised during an 90 implementation of RFC 4893. Thus the goal of this document is to 91 point out the areas of clarification required in the 4-byte AS number 92 specification[1]. Besides the clarification text, it also proposes a 93 notification message and clearly defines the processing of "MY AS 94 Number" field in BGP[2] when 4-byte AS number capability message is 95 present. 97 3. Terminology 99 OLD BGP Speaker: A BGP speaker which is RFC 4271[2] compliant and 100 does not implement 4byte extension to the AS number as defined in RFC 101 4893. 103 NEW BGP Speaker: A BGP speaker which implements the 4-byte AS number 104 support as defined in RFC 4893. 106 4. Clarification issue-I 108 RFC4893 is unclear about the processing of "My AS Number" field in 109 the OPEN message[2]. Section 3 mentions about the capability message 110 for 4byte ASN support: "The Capability that is used by a BGP speaker 111 to convey to its BGP peer the 4-octet Autonomous System number 112 capability, also carries the 4-octet Autonomous System number of the 113 speaker in the Capability Value field of the Capability Optional 114 Parameter. The Capability Length field of the Capability is set to 115 4. " and "We denote this special AS number as AS_TRANS for ease of 116 description in the rest of this specification. This AS number is 117 also placed in the "My Autonomous System" field of the OPEN message 118 originated by a NEW BGP speaker, if the speaker does not have a 119 (globally unique) 2-octet AS number." 121 The questions are : 1) When 4-byte AS number capability message is 122 present and the receiver is able to process the capability message, 123 should it ignore the AS number field in the OPEN message? [ note: 124 2-byte mappable As Numbered BGP speaker may send 4-byte AS capability 125 support] 127 4.1. Proposal for new text 129 A separate section on handling OPEN message would be very useful. A 130 suggested text is below. 132 Processing and sending OPEN message: 133 1) Sending OPEN message:If the BGP speaker has a 2byte AS number 134 or 2-byte mappable 4-byte AS number, it uses the 2 byte ASN in the 135 "My AS number" field of OPEN message. If the BGP speaker has a 136 4-byte non-mappable AS number, then it uses AS_TRANS in "My AS 137 Number" field of OPEN message. 138 2) Receiving OPEN message: If a NEW BGP speaker receives a OPEN 139 message with extended AS number capability, then it uses the 140 4-byte AS number from the extended AS capability message and may 141 disregard the value in the "My AS number" field in the OPEN 142 message. If there is no extended AS capability is present and the 143 OPEN messge "My AS number" field contains AS_TRANS, then the NEW 144 BGP implementation sends a notification message to the peer and 145 closes connection. An OLD BGP speaker-implementation is not aware 146 of the extended AS number capability; it processes the OPEN 147 message as per RFC 4271. 149 5. Clarification - issue-2 151 Currently, in section 4.2.1 RFC 4893 states: 153 "Note that peering between a NEW BGP speaker and an OLD one is 154 possible only if the NEW BGP speaker has a 2-octet AS number. 155 However, this document does not assume that an Autonomous System with 156 NEW speakers has to have a globally unique 2-octet AS number - 157 AS_TRANS could be used instead (even if a multiple Autonomous System 158 would use it)." 159 R1 R2 R3 R4 160 o-------------------o-------------------o----------------------o 161 OLD NEW OLD NEW 162 (50) (77777) (100) (65666) 164 A scenario with OLD and NEW BGP speakers 166 In the above scenario, if both R2 and R4 peer with R3, R3 167 configuration may assume that R4 and R2 are part of same AS. This 168 may cause R3 to make undesirable routing decision. Some 169 clarification/recommendation is required in this case. 171 5.1. Proposal for new text 173 Note that peering between a NEW BGP speaker and an OLD one is 174 possible only if the NEW BGP speaker has a 2-octet AS number or a 175 2-octet mappable extended AS number. However, this document does not 176 assume that an Autonomous System with NEW speakers has to have a 177 globally unique 2-octet AS number - AS_TRANS could be used 178 instead;careful considerations are required such that it does not 179 affect the routing path of the traffic due to some local policy on AS 180 number at the OLD BGP speaker. During transition to NEW BGP speaker 181 from an OLD BGP speaker, the above scenario should be avoided. 183 6. Clarification - issue-3 185 Section 3 of RFC4893 states: "NEW BGP speakers carry AS path 186 information expressed in terms of 4-octet Autonomous Systems numbers 187 by using the existing AS_PATH attribute, except that each AS number 188 in this attribute is encoded not as a 2-octet, but as a 4-octet 189 entity." 191 R1 R2 R3 R4 192 o-------------------o-------------------o----------------------o 193 NEW NEW OLD NEW 194 (77777) (65666) (100) (200) 196 2nd scenario with OLD and NEW BGP speakers 198 According to the current specification, R1 will send AS_PATH with 199 4-byte AS numbers to R2. Since R2 is peering with an OLD BGP 200 speaker, it will make the conversion of 4-byte AS_PATH attributes to 201 2-byte AS_PATH attributes and pass them to R3 along with AS4_PATH 202 attributes. 204 Since OLD and NEW BGP speakers will exist in the network for a long 205 time, it might be clean to use 4-byte numbers in AS4_PATH attributes 206 only and corresponding value AS_TRANS in AS_PATH attribute even when 207 two NEW BGP peers with non-mappable 4-byte AS number exchange 208 information. It also simplifies the NEW BGP speaker implementation 209 and processing of AS_PATH. This simplifies the NEW BGP 210 implementation and saves the extra time in processing an UPDATE 211 message. 213 6.1. Proposal for change in protocol 215 A NEW BGP speaker with 4-byte AS number always includes AS4_PATH 216 attribute containing the extended 4-byte AS number. If the AS number 217 is 2-byte mappable, then it adds the corresponding 2-byte mapped AS 218 number in the AS_PATH attribute, otherwise it uses AS_TRANS as the AS 219 number in the corresponding AS_PATH attribute. Thus the NEW BGP 220 speaker will always have AS4_PATH and a corresponding AS_PATH 221 attribute. Following a complete transition to 4-byte AS numbered 222 systems, AS_PATH may be replaced by AS4_PATH by turning a 223 configuration knob on each system. Thus a NEW BGP implementation may 224 consider providing a configuration knob which disables AS_PATH 225 attribute sending and processing. 227 7. Calrification issue-4 229 Minor nit: "truly 4-octet" should be defined as a quantity higher 230 than 65535. 232 Should the NEW BGP speaker send a NOTIFICATION message when it 233 receives a OPEN message with AS_TRANS but without any corresponding 234 capability message ? Note that although AS_TRANS(23456) is a 235 reserved number now, it is still possible to receive a OPEN message 236 with AS_TRANS value from an OLD BGP speaker or from a ill-behaving 237 NEW BGP speaker. 239 8. Proposal for a NOTIFICATION message 241 When two BGP speakers correspond with each other by sending AS_TRANS 242 value in the 'My AS number' field, then the OPEN message MUST contain 243 the 4-octet AS number capability option. If the 4-octet capability 244 is missing in OPEN message where the 'My AS Number' field contains 245 AS_TRANS value, a NEW BGP speaker-receiver SHOULD send a notification 246 with code=2, subcode=2 [bad peer AS] to the sender of the OPEN 247 message. 249 If an OLD BGP speaker receives a OPEN message with AS_TRANS value in 250 the 'My AS number' field it should treat it normally as per RFC 4271 251 and local policy. 253 9. IANA Considerations 255 This document has no actions for IANA. 257 10. Acknowledgements 259 11. Normative References 261 [1] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number 262 Space", RFC 4893, May 2007. 264 [2] Rekhter, Y., Li, T., and S. Hares, "Border Gateway Protocol 4", 265 RFC 4271, January 2006. 267 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 268 Levels", BCP 14, RFC 2119, March 1997. 270 Author's Address 272 Samita Chakrabarti 273 IP Infusion - An Access Company 274 125 S. Market Street 275 San Jose 276 USA 278 Email: samitac@ipinfusion.com 280 Full Copyright Statement 282 Copyright (C) The IETF Trust (2008). 284 This document is subject to the rights, licenses and restrictions 285 contained in BCP 78, and except as set forth therein, the authors 286 retain all their rights. 288 This document and the information contained herein are provided on an 289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 291 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 292 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 293 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 296 Intellectual Property 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at 318 ietf-ipr@ietf.org. 320 Acknowledgment 322 Funding for the RFC Editor function is provided by the IETF 323 Administrative Support Activity (IASA).