idnits 2.17.1 draft-ietf-sidr-origin-validation-signaling-06.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 10, 2015) is 3083 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 171, 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 13, 2016 Cisco 6 J. Scudder 7 Juniper Networks 8 D. Ward 9 Cisco 10 R. Bush 11 Internet Initiative Japan, Inc. 12 November 10, 2015 14 BGP Prefix Origin Validation State Extended Community 15 draft-ietf-sidr-origin-validation-signaling-06 17 Abstract 19 As part of the origination AS validation process, it can be desirable 20 to automatically consider the validation state of routes in the BGP 21 decision process. The purpose of this document is to provide a 22 specification for doing so. The document also defines a new BGP 23 opaque extended community to carry the validation state inside an 24 autonomous system to influence the decision process of the IBGP 25 speakers. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 13, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 63 2. Origin Validation State Extended Community . . . . . . . . . 2 64 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 As part of the origination AS validation process, it can be desirable 74 to automatically consider the validation state of routes in the BGP 75 decision process. The purpose of this document is to provide a 76 specification for doing so. The document defines a new BGP opaque 77 extended community to carry the validation state inside an autonomous 78 system to influence the decision process of the IBGP speakers. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Origin Validation State Extended Community 88 The origin validation state extended community is an opaque extended 89 community [RFC4360] with the following encoding: 91 0 1 2 3 92 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 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | 0x43 | TBD | Reserved | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Reserved |validationstate| 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 The value of the high-order octet of the extended Type Field is 0x43, 100 which indicates it is non-transitive. The value of the low-order 101 octet of the extended type field as assigned by IANA is 0x00. The 102 last octet of the extended community encodes the route's validation 103 state [RFC6811]. It can assume the following values: 105 +-------+-----------------------------+ 106 | Value | Meaning | 107 +-------+-----------------------------+ 108 | 0 | Lookup result = "valid" | 109 | 1 | Lookup result = "not found" | 110 | 2 | Lookup result = "invalid" | 111 +-------+-----------------------------+ 113 If the router is configured to support the extensions defined in this 114 draft, it SHOULD attach the origin validation state extended 115 community to BGP UPDATE messages sent to IBGP peers by mapping the 116 computed validation state in the last octet of the extended 117 community. Similarly on the receiving IBGP speakers, the validation 118 state of an IBGP route SHOULD be derived directly from the last octet 119 of the extended community, if present. 121 An implementation SHOULD NOT send more than one instance of the 122 origin validation state extended community. However, if more than 123 one instance is received, an implementation MUST disregard all 124 instances other than the one with the numerically-greatest value. If 125 the value received is greater than the largest specified value (2), 126 the implementation MUST apply a strategy similar to attribute discard 127 [RFC7606] by discarding the erroneous community and logging the error 128 for further analysis. 130 By default, implementations SHOULD drop the origin validation state 131 extended community if received from an EBGP peer, without further 132 processing it. However an implementation MAY be configured to accept 133 the community when warranted, for example when the EBGP session is to 134 a neighbor AS under control of the same administration. Similarly, 135 an implementation SHOULD NOT send the community to EBGP peers but MAY 136 be configured to do so if warranted. 138 3. Deployment Considerations 140 In deployment scenarios where not all the speakers in an autonomous 141 system are upgraded to support the extensions defined in this 142 document, it is necessary to define policies that match on the origin 143 validation extended community and set another BGP attribute [RFC6811] 144 that influences the best path selection the same way as what would 145 have been enabled by an implementation of this extension. 147 4. Acknowledgements 149 The authors would like to acknowledge the valuable review and 150 suggestions from Wesley George, Roque Gagliano and Bruno Decraene on 151 this document. 153 5. IANA Considerations 155 IANA has assigned a value 0x00 from the "BGP Opaque Extended 156 Community" type registry in the non-transitive range, which is called 157 "BGP Origin Validation State Extended Community". 159 6. Security Considerations 161 This document introduces no new security concerns beyond what is 162 described in [RFC6811]. 164 7. Normative References 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, 168 DOI 10.17487/RFC2119, March 1997, 169 . 171 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 172 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 173 DOI 10.17487/RFC4271, January 2006, 174 . 176 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 177 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 178 February 2006, . 180 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 181 Austein, "BGP Prefix Origin Validation", RFC 6811, 182 DOI 10.17487/RFC6811, January 2013, 183 . 185 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 186 Patel, "Revised Error Handling for BGP UPDATE Messages", 187 RFC 7606, DOI 10.17487/RFC7606, August 2015, 188 . 190 Authors' Addresses 192 Pradosh Mohapatra 193 Sproute Networks 195 Email: mpradosh@yahoo.com 197 Keyur Patel 198 Cisco 199 170 W. Tasman Drive 200 San Jose, CA 95124 202 Email: keyupate@cisco.com 204 John Scudder 205 Juniper Networks 206 1194 N. Mathilda Ave 207 Sunnyvale, CA 94089 209 Email: jgs@juniper.net 211 Dave Ward 212 Cisco 213 170 W. Tasman Drive 214 San Jose, CA 95124 216 Email: dward@cisco.com 218 Randy Bush 219 Internet Initiative Japan, Inc. 220 5147 Crystal Springs 221 Bainbridge Island, Washington 98110 223 Email: randy@psg.com