idnits 2.17.1 draft-ietf-sidr-origin-validation-signaling-05.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 4, 2015) is 3097 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 170, 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 7, 2016 Cisco 6 J. Scudder 7 Juniper Networks 8 D. Ward 9 Cisco 10 R. Bush 11 Internet Initiative Japan, Inc. 12 November 4, 2015 14 BGP Prefix Origin Validation State Extended Community 15 draft-ietf-sidr-origin-validation-signaling-05 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 7, 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. 120 An implementation SHOULD NOT send more than one instance of the 121 origin validation state extended community. However, if more than 122 one instance is received, an implementation MUST disregard all 123 instances other than the one with the numerically-greatest value. If 124 the value received is greater than the largest specified value (2), 125 the implementation MUST apply a strategy similar to attribute discard 126 [RFC7606] by discarding the erroneous community and logging the error 127 for further analysis. 129 By default, implementations SHOULD drop the origin validation state 130 extended community if received from an EBGP peer, without further 131 processing it. However an implementation MAY be configured to accept 132 the community when warranted, for example when the EBGP session is to 133 a neighbor AS under control of the same administration. Similarly, 134 an implementation SHOULD NOT send the community to EBGP peers but MAY 135 be configured to do so if warranted. 137 3. Deployment Considerations 139 In deployment scenarios where not all the speakers in an autonomous 140 system are upgraded to support the extensions defined in this 141 document, it is necessary to define policies that match on the origin 142 validation extended community and set another BGP attribute [RFC6811] 143 that influences the best path selection the same way as what would 144 have been enabled by an implementation of this extension. 146 4. Acknowledgements 148 The authors would like to acknowledge the valuable review and 149 suggestions from Wesley George, Roque Gagliano and Bruno Decraene on 150 this document. 152 5. IANA Considerations 154 IANA has assigned a value 0x00 from the "BGP Opaque Extended 155 Community" type registry in the non-transitive range, which is called 156 "BGP Origin Validation State Extended Community". 158 6. Security Considerations 160 This document introduces no new security concerns beyond what is 161 described in [RFC6811]. 163 7. Normative References 165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, 167 DOI 10.17487/RFC2119, March 1997, 168 . 170 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 171 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 172 DOI 10.17487/RFC4271, January 2006, 173 . 175 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 176 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 177 February 2006, . 179 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 180 Austein, "BGP Prefix Origin Validation", RFC 6811, 181 DOI 10.17487/RFC6811, January 2013, 182 . 184 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 185 Patel, "Revised Error Handling for BGP UPDATE Messages", 186 RFC 7606, DOI 10.17487/RFC7606, August 2015, 187 . 189 Authors' Addresses 191 Pradosh Mohapatra 192 Sproute Networks 194 Email: mpradosh@yahoo.com 196 Keyur Patel 197 Cisco 198 170 W. Tasman Drive 199 San Jose, CA 95124 201 Email: keyupate@cisco.com 203 John Scudder 204 Juniper Networks 205 1194 N. Mathilda Ave 206 Sunnyvale, CA 94089 208 Email: jgs@juniper.net 210 Dave Ward 211 Cisco 212 170 W. Tasman Drive 213 San Jose, CA 95124 215 Email: dward@cisco.com 217 Randy Bush 218 Internet Initiative Japan, Inc. 219 5147 Crystal Springs 220 Bainbridge Island, Washington 98110 222 Email: randy@psg.com