idnits 2.17.1 draft-ietf-sidr-origin-validation-signaling-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (November 12, 2015) is 3088 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) == Unused Reference: 'RFC4271' is defined on line 168, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR P. Mohapatra 3 Internet-Draft Sproute Networks 4 Intended status: Standards Track K. Patel 5 Expires: May 15, 2016 Cisco 6 J. Scudder 7 Juniper Networks 8 D. Ward 9 Cisco 10 R. Bush 11 Internet Initiative Japan, Inc. 12 November 12, 2015 14 BGP Prefix Origin Validation State Extended Community 15 draft-ietf-sidr-origin-validation-signaling-07 17 Abstract 19 This document defines a new BGP opaque extended community to carry 20 the origination AS validation state inside an autonomous system. 21 IBGP speakers that receive this validation state can configure local 22 policies allowing it to influence their decision process. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 15, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 60 2. Origin Validation State Extended Community . . . . . . . . . 2 61 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 3 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 68 1. Introduction 70 This document defines a new BGP opaque extended community to carry 71 the origination AS validation state inside an autonomous system. 72 IBGP speakers that receive this validation state can configure local 73 policies allowing it to influence their decision process. 75 1.1. Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 2. Origin Validation State Extended Community 83 The origin validation state extended community is an opaque extended 84 community [RFC4360] with the following encoding: 86 0 1 2 3 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | 0x43 | 0x00 | Reserved | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Reserved |validationstate| 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 The value of the high-order octet of the extended Type Field is 0x43, 95 which indicates it is non-transitive. The value of the low-order 96 octet of the extended type field as assigned by IANA is 0x00. The 97 Reserved field MUST be set to 0 and ignored upon the receipt of this 98 community. The last octet of the extended community encodes the 99 route's validation state [RFC6811]. It can assume the following 100 values: 102 +-------+-----------------------------+ 103 | Value | Meaning | 104 +-------+-----------------------------+ 105 | 0 | Lookup result = "valid" | 106 | 1 | Lookup result = "not found" | 107 | 2 | Lookup result = "invalid" | 108 +-------+-----------------------------+ 110 If the router is configured to support the extensions defined in this 111 draft, it SHOULD attach the origin validation state extended 112 community to BGP UPDATE messages sent to IBGP peers by mapping the 113 computed validation state in the last octet of the extended 114 community. Similarly on the receiving IBGP speakers, the validation 115 state of an IBGP route SHOULD be derived directly from the last octet 116 of the extended community, if present. 118 An implementation SHOULD NOT send more than one instance of the 119 origin validation state extended community. However, if more than 120 one instance is received, an implementation MUST disregard all 121 instances other than the one with the numerically-greatest validation 122 state value. If the value received is greater than the largest 123 specified value (2), the implementation MUST apply a strategy similar 124 to attribute discard [RFC7606] by discarding the erroneous community 125 and logging the error for further analysis. 127 By default, implementations SHOULD drop the origin validation state 128 extended community if received from an EBGP peer, without further 129 processing it. However an implementation MAY be configured to accept 130 the community when warranted, for example when the EBGP session is to 131 a neighbor AS under control of the same administration. Similarly, 132 an implementation SHOULD NOT send the community to EBGP peers but MAY 133 be configured to do so if warranted. 135 3. Deployment Considerations 137 In deployment scenarios where not all the speakers in an autonomous 138 system are upgraded to support the extensions defined in this 139 document, it is necessary to define policies that match on the origin 140 validation extended community and set another BGP attribute [RFC6811] 141 that influences the best path selection the same way as what would 142 have been enabled by an implementation of this extension. 144 4. Acknowledgements 146 The authors would like to acknowledge the valuable review and 147 suggestions from Wesley George, Roque Gagliano and Bruno Decraene on 148 this document. 150 5. IANA Considerations 152 IANA has assigned a value 0x00 from the "BGP Opaque Extended 153 Community" type registry in the non-transitive range, which is called 154 "BGP Origin Validation State Extended Community". 156 6. Security Considerations 158 This document introduces no new security concerns beyond what is 159 described in [RFC6811]. 161 7. Normative References 163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 164 Requirement Levels", BCP 14, RFC 2119, 165 DOI 10.17487/RFC2119, March 1997, 166 . 168 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 169 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 170 DOI 10.17487/RFC4271, January 2006, 171 . 173 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 174 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 175 February 2006, . 177 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 178 Austein, "BGP Prefix Origin Validation", RFC 6811, 179 DOI 10.17487/RFC6811, January 2013, 180 . 182 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 183 Patel, "Revised Error Handling for BGP UPDATE Messages", 184 RFC 7606, DOI 10.17487/RFC7606, August 2015, 185 . 187 Authors' Addresses 188 Pradosh Mohapatra 189 Sproute Networks 191 Email: mpradosh@yahoo.com 193 Keyur Patel 194 Cisco 195 170 W. Tasman Drive 196 San Jose, CA 95124 198 Email: keyupate@cisco.com 200 John Scudder 201 Juniper Networks 202 1194 N. Mathilda Ave 203 Sunnyvale, CA 94089 205 Email: jgs@juniper.net 207 Dave Ward 208 Cisco 209 170 W. Tasman Drive 210 San Jose, CA 95124 212 Email: dward@cisco.com 214 Randy Bush 215 Internet Initiative Japan, Inc. 216 5147 Crystal Springs 217 Bainbridge Island, Washington 98110 219 Email: randy@psg.com