idnits 2.17.1 draft-dhrao-idr-4octet-extcomm-generic-subtype-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 241. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 21, 2008) is 5659 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) == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-as4octet-ext-community-00 ** Downref: Normative reference to an Informational RFC: RFC 1998 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Rao 3 Internet-Draft P. Mohapatra 4 Intended status: Standards Track Cisco Systems 5 Expires: April 24, 2009 J. Haas 6 Arbor Networks 7 October 21, 2008 9 Generic Subtype for BGP Four-octet AS specific extended community 10 draft-dhrao-idr-4octet-extcomm-generic-subtype-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 24, 2009. 37 Abstract 39 Maintaining the current best practices with communities, ISPs and 40 enterprises that get assigned a 4-octet AS number may want the BGP 41 UPDATE messages they receive from their customers or peers to include 42 a 4-octet AS specific extended community. This document defines a 43 new sub-type within the four-octet AS specific extended community to 44 facilitate this practice. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 50 2. Generic Subtype Definition . . . . . . . . . . . . . . . . . . 3 51 3. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 52 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 53 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 57 Intellectual Property and Copyright Statements . . . . . . . . . . 7 59 1. Introduction 61 Maintaining the current best practices with communities, ISPs and 62 enterprises that get assigned a 4-octet AS number may want the BGP 63 UPDATE messages they receive from their customers or peers to include 64 a 4-octet AS specific extended community. This document defines a 65 new sub-type within the four-octet AS specific extended community to 66 facilitate this practice. 68 As an example, [RFC1998] describes an application of BGP community 69 attribute ([RFC1997]) to implement flexible routing policies for 70 sites multi-homed to one or multiple providers. In a two-octet AS 71 environment, the advertised routes are usually associated with a 72 community attribute that encodes the provider's AS number in the 73 first two octets of the community and a LOCAL_PREF value in the 74 second two octets of the community. The community attribute signals 75 the provider edge routers connected to the site to set the 76 corresponding LOCAL_PREF on their advertisements to the IBGP mesh. 77 In this way, customers can put into practice topologies like active- 78 backup. 80 When such a provider is assigned a four-octet AS number, the existing 81 mechanism of using communities is not sufficient since the community 82 value can not exceed four bytes. The natural alternative is to 83 extend the same mechanism using extended communities since it allows 84 for encoding eight bytes of information. 86 [I-D.ietf-l3vpn-as4octet-ext-community] defines four-octet AS 87 specific extended community with a designated type field. At the 88 time of writing this document, there are two known sub-types defined: 89 Four-octet specific Route Target extended community and Four-octet 90 specific Route Origin extended community. This document specifies a 91 generic sub-type for the four-octet AS specific extended community to 92 provide benefits such as the one cited above as the Internet migrates 93 to four-octet AS space. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Generic Subtype Definition 102 0 1 2 3 103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | 0x02 | 0x04 | Four-Octet AS | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Four-Octet AS (cont.) | Local Administrator | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 This is a transitive extended community with Type Field comprising of 111 2 octets and Value Field comprising of 6 octets. 113 The high-order octet of this extended type is set to 0x02 as defined 114 in [I-D.ietf-l3vpn-as4octet-ext-community]. The low-order octet or 115 the sub-type is set to 0x04. 117 The Value Field consists of two sub-fields: 119 Global Administrator sub-field: 4 octets 121 This sub-field contains a four-octet Autonomous System number. 123 Local Administrator sub-field: 2 octets 125 This sub-field contains a value that can influence 126 routing policies. It is expected that the values 127 will be identical to the ones used in practice with standard 128 communities and will be of significance between the local 129 Autonomous System and its customer or peering Autonomous 130 Systems. 132 3. Deployment Considerations 134 A speaker with a 4-octet Autonomous System may have a customer or 135 peer with a 2-octet Autonomous System. If such a peer supports 136 4-octet extended communities, then it will be able to tag its routes 137 with the 4-octet extended community defined by the speaker. If the 138 peer does not support 4-octet extended communities, then the speaker 139 may need to define an appropriate standard community value for the 140 same purpose. 142 Similarly, a 2-octet AS may have two valid representations as either 143 a standard community or a 4-octet extended community with the upper 144 two octets of the AS set to zero. Therefore, as per 145 [I-D.ietf-l3vpn-as4octet-ext-community], two-octet ASes SHOULD use 146 standard 2-octet communities rather than 4-octet AS specific extended 147 communities in order to avoid inconsistencies. 149 4. Acknowledgments 151 5. IANA Considerations 153 IANA is requested to assign sub-type 0x04 as a generic four-octet AS 154 specific extended community. 156 6. Security Considerations 158 There are no additional security risks introduced by this design. 160 7. Normative References 162 [I-D.ietf-l3vpn-as4octet-ext-community] 163 Rekhter, Y., Sangli, S., and D. Tappan, "Four-octet AS 164 Specific BGP Extended Community", 165 draft-ietf-l3vpn-as4octet-ext-community-00 (work in 166 progress), September 2008. 168 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 169 Communities Attribute", RFC 1997, August 1996. 171 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 172 Community Attribute in Multi-home Routing", RFC 1998, 173 August 1996. 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1997. 178 Authors' Addresses 180 Dhananjaya Rao 181 Cisco Systems 182 170 W. Tasman Drive 183 San Jose, CA 95134 184 USA 186 Email: dhrao@cisco.com 187 Pradosh Mohapatra 188 Cisco Systems 189 170 W. Tasman Drive 190 San Jose, CA 95134 191 USA 193 Email: pmohapat@cisco.com 195 Jeffrey Haas 196 Arbor Networks 197 2727 S. State St. 198 Ann Arbor, MI 48104 199 USA 201 Email: jhaas@arbor.net 203 Full Copyright Statement 205 Copyright (C) The IETF Trust (2008). 207 This document is subject to the rights, licenses and restrictions 208 contained in BCP 78, and except as set forth therein, the authors 209 retain all their rights. 211 This document and the information contained herein are provided on an 212 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 213 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 214 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 215 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 216 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 219 Intellectual Property 221 The IETF takes no position regarding the validity or scope of any 222 Intellectual Property Rights or other rights that might be claimed to 223 pertain to the implementation or use of the technology described in 224 this document or the extent to which any license under such rights 225 might or might not be available; nor does it represent that it has 226 made any independent effort to identify any such rights. Information 227 on the procedures with respect to rights in RFC documents can be 228 found in BCP 78 and BCP 79. 230 Copies of IPR disclosures made to the IETF Secretariat and any 231 assurances of licenses to be made available, or the result of an 232 attempt made to obtain a general license or permission for the use of 233 such proprietary rights by implementers or users of this 234 specification can be obtained from the IETF on-line IPR repository at 235 http://www.ietf.org/ipr. 237 The IETF invites any interested party to bring to its attention any 238 copyrights, patents or patent applications, or other proprietary 239 rights that may cover technology that may be required to implement 240 this standard. Please address the information to the IETF at 241 ietf-ipr@ietf.org.