idnits 2.17.1 draft-ietf-l3vpn-as4octet-ext-community-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter (Juniper Networks) 3 Internet Draft Srihari R. Sangli (Cisco Systems) 4 Expiration Date: September 2009 Daniel Tappan 5 Intended Status: Proposed Standard 7 Four-octet AS Specific BGP Extended Community 9 draft-ietf-l3vpn-as4octet-ext-community-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright and License Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 This document may contain material from IETF Documents or IETF 43 Contributions published or made publicly available before November 44 10, 2008. The person(s) controlling the copyright in some of this 45 material may not have granted the IETF Trust the right to allow 46 modifications of such material outside the IETF Standards Process. 47 Without obtaining an adequate license from the person(s) controlling 48 the copyright in such materials, this document may not be modified 49 outside the IETF Standards Process, and derivative works of it may 50 not be created outside the IETF Standards Process, except to format 51 it for publication as an RFC or to translate it into languages other 52 than English. 54 Abstract 56 This document defines a new type of a BGP extended community - four- 57 octet AS specific extended community. This community allows to carry 58 4 octet autonomous system numbers. 60 Specification of Requirements 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 1. Introduction 68 This document defines a new type of BGP extended community 69 ([RFC4360]) - four-octet AS specific extended community. This type of 70 extended community is similar to the two-octet AS specific extended 71 community, except that it can carry a four octets autonomous system 72 number. 74 2. Four-octet AS specific extended community 76 This is an extended type with Type Field comprising of 2 octets and 77 Value Field comprising of 6 octets. 79 0 1 2 3 80 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 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | 0x02 or 0x42 | Sub-Type | Global Administrator : 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 : Global Administrator (cont.) | Local Administrator | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 The value of the high-order octet of this extended type is either 88 0x02 (for transitive communities) or 0x42 (for non-transitive commu- 89 nities). The low-order octet of this extended type is used to 90 indicate sub-types. 92 The Value Field consists of two sub-fields: 94 Global Administrator sub-field: 4 octets 96 This sub-field contains a 4-octets Autonomous System number 97 assigned by IANA. 99 Local Administrator sub-field: 2 octets 101 The organization identified by Autonomous System number in the 102 Global Administrator sub-field, can encode any information in 103 this sub-field. The format and meaning of the value encoded in 104 this sub-field should be defined by the sub-type of the commu- 105 nity. 107 3. Considerations for two-octet Autonomous Systems 109 As per [RFC4893], a two-octet Autonomous System number can be con- 110 verted into a 4-octet Autonomous System number by setting the two 111 high-order octets of the 4-octet field to zero. 113 As a consequence, at least in principle an autonomous system that 114 uses a two-octet Autonomous System number could use either two-octet 115 or four-octet AS specific extended communities. This is undesirable, 116 as both communities would be treated as different, even if they had 117 the same Sub-Type and Local Administrator values. 119 Therefore, for backward compatibility with existing deployments, and 120 to avoid inconsistencies between two-octet and four-octet specific 121 extended communities, autonomous systems that use two-octet 122 Autonomous System numbers SHOULD use two-octet AS specific extended 123 communities rather than four-octet AS specific extended communities. 125 4. IANA Considerations 127 This document defines a class of extended communities called four- 128 octet AS specific extended community for which the IANA is to create 129 and maintain a registry entitled Four-octet AS Specific Extended Com- 130 munity. All the communities in this class are of extended Types. 131 Future assignment are to be made using the "First Come First Served" 132 policy defined in [RFC5226]. The Type values for the transitive com- 133 munities of the four-octet AS specific extended community class are 134 0x0200-0x02ff, and for the non-transitive communities of that class 135 are 0x4200-0x42ff. Assignments consist of a name and the value. 137 This document makes the following assignments for the four-octet AS 138 specific extended community: 140 Name Type Value 141 ---- ---------- 142 four-octet AS specific Route Target 0x0202 143 four-octet AS specific Route Origin 0x0203 145 5. Security Considerations 147 All the security considerations for BGP Extended Communities apply 148 here. 150 6. Acknowledgements 152 Thanks to Bruno Decraene for his contributions to this document. 154 7. Normative References 156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 157 Requirement Levels", BCP 14, RFC 2119, March 1997. 159 [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 160 Considerations Section in RFCs", RFC5226, May 2008. 162 [RFC4360] Srihari R. Sangli, Daniel Tappan, Yakov Rekhter, "BGP 163 Extended Communities Attribute", RFC 4360, February 2006. 165 [RFC4893] Vohra, Q., Chen, E., "BGP Support for Four-octet AS Number 166 Space", RFC 4893, May 2007. 168 8. Non-normative References 170 9. Author Information 172 Yakov Rekhter 173 Juniper Networks, Inc. 174 e-mail: yakov@juniper.net 176 Srihari R. Sangli 177 Cisco Systems, Inc. 178 e-mail: rsrihari@cisco.com 180 Dan Tappan 181 Boxborough MA 182 e-mail: Dan.Tappan@Gmail.com