idnits 2.17.1 draft-ietf-sidr-origin-validation-signaling-01.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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.) -- The document date (August 3, 2011) is 4622 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 (-10) exists of draft-ietf-sidr-pfx-validate-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Mohapatra 3 Internet-Draft K. Patel 4 Intended status: Standards Track Cisco Systems 5 Expires: February 4, 2012 J. Scudder 6 D. Ward 7 Juniper Networks 8 R. Bush 9 Internet Initiative Japan, Inc. 10 August 3, 2011 12 BGP Prefix Origin Validation State Extended Community 13 draft-ietf-sidr-origin-validation-signaling-01 15 Abstract 17 As part of the origination AS validation process, it can be desirable 18 to automatically consider the validation state of routes in the BGP 19 decision process. The purpose of this document is to provide a 20 specification for doing so. The document also defines a new BGP 21 opaque extended community to carry the validation state inside an 22 autonomous system to influence the decision process of the IBGP 23 speakers. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 4, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 73 2. Origin Validation State Extended Community . . . . . . . . . . 4 74 3. Changes to the BGP Decision Process . . . . . . . . . . . . . . 5 75 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 5 76 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 77 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 85 1. Introduction 87 As part of the origination AS validation process, it can be desirable 88 to automatically consider the validation state of routes in the BGP 89 decision process. The purpose of this document is to provide a 90 specification for doing so. The document defines a new BGP opaque 91 extended community to carry the validation state inside an autonomous 92 system to influence the decision process of the IBGP speakers. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Origin Validation State Extended Community 102 The origin validation state extended community is an opaque extended 103 community [RFC4360] with the following encoding: 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | 0x43 | TBD | Reserved | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Reserved |validationstate| 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 The value of the high-order octet of the extended Type Field is 0x43, 114 which indicates it is non-transitive. The value of the low-order 115 octet of the extended type field for this community is TBD. The last 116 octet of the extended community encodes the route's validation 117 state([I-D.ietf-sidr-pfx-validate]. It can assume the following 118 values: 120 +-------+-----------------------------+ 121 | Value | Meaning | 122 +-------+-----------------------------+ 123 | 0 | Lookup result = "valid" | 124 | 1 | Lookup result = "not found" | 125 | 2 | Lookup result = "invalid" | 126 +-------+-----------------------------+ 128 If the router is configured to support the extensions defined in this 129 draft, it SHOULD attach the origin validation state extended 130 community to BGP UPDATE messages sent to IBGP peers by mapping the 131 computed validation state in the last octet of the extended 132 community. Similarly on the receiving IBGP speakers, the validation 133 state of an IBGP route SHOULD be derived directly from the last octet 134 of the extended community, if present. Note that routers do not 135 perform prefix origin validation (compute the validation state as 136 defined in [I-D.ietf-sidr-pfx-validate]) for IBGP learnt routes. 138 3. Changes to the BGP Decision Process 140 If a BGP router supports prefix origin validation and is configured 141 for the extensions defined in this document, the validation step MUST 142 be performed prior to any of the steps defined in the decision 143 process of [RFC4271]. The validation step is stated as follows: 145 When comparing a pair of routes for a BGP destination, the route 146 with the lowest "validation state" value is preferred. 148 In all other respects, the decision process remains unchanged. 150 3.1. Policy Control 152 It MUST be possible to enable or disable the validation step as 153 defined in Section 3 through configuration. The default SHOULD be 154 for the validation step to be disabled. 156 4. Deployment Considerations 158 In deployment scenarios where not all the speakers in an autonomous 159 system are upgraded to support the extensions defined in this 160 document, it is necessary to define policies that match on the origin 161 validation extended community and set another BGP attribute 162 [I-D.ietf-sidr-pfx-validate] that influences the best path selection 163 the same way as what would have been enabled by an implementation of 164 this extension. 166 5. Acknowledgements 168 The authors would like to acknowledge the valuable review and 169 suggestions from Wesley George and Roque Gagliano on this document. 171 6. IANA Considerations 173 IANA shall assign a new value from the "BGP Opaque Extended 174 Community" type registry from the non-transitive range, to be called 175 "BGP Origin Validation State Extended Community". 177 7. Security Considerations 179 This document introduces no new security concerns beyond what is 180 described in [I-D.ietf-sidr-pfx-validate]. 182 8. References 184 8.1. Normative References 186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", BCP 14, RFC 2119, March 1997. 189 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 190 Protocol 4 (BGP-4)", RFC 4271, January 2006. 192 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 193 Communities Attribute", RFC 4360, February 2006. 195 8.2. Informative References 197 [I-D.ietf-sidr-pfx-validate] 198 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 199 Austein, "BGP Prefix Origin Validation", 200 draft-ietf-sidr-pfx-validate-02 (work in progress), 201 July 2011. 203 Authors' Addresses 205 Pradosh Mohapatra 206 Cisco Systems 207 170 W. Tasman Drive 208 San Jose, CA 95134 209 USA 211 Email: pmohapat@cisco.com 212 Keyur Patel 213 Cisco Systems 214 170 W. Tasman Drive 215 San Jose, CA 95134 216 USA 218 Email: keyupate@cisco.com 220 John Scudder 221 Juniper Networks 222 1194 N. Mathilda Ave 223 Sunnyvale, CA 94089 224 USA 226 Email: jgs@juniper.net 228 David Ward 229 Juniper Networks 230 1194 N. Mathilda Ave 231 Sunnyvale, CA 94089 232 USA 234 Email: dward@juniper.net 236 Randy Bush 237 Internet Initiative Japan, Inc. 238 5147 Crystal Springs 239 Bainbridge Island, Washington 98110 240 USA 242 Email: randy@psg.com