idnits 2.17.1 draft-pmohapat-sidr-origin-validation-signaling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Since the extended community is defined to be non-transitive, it MUST not be attached while advertising routes to EBGP peers. Additionally, if it is present in an UPDATE message received from an EBGP peer, the router MUST remove the origin validation state extended community before parsing rest of the message. == 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 (April 26, 2010) is 5107 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 (-07) exists of draft-pmohapat-sidr-pfx-validate-06 Summary: 1 error (**), 0 flaws (~~), 4 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: October 28, 2010 J. Scudder 6 D. Ward 7 Juniper Networks 8 R. Bush 9 Internet Initiative Japan, Inc. 10 April 26, 2010 12 BGP Prefix Origin Validation State Extended Community 13 draft-pmohapat-sidr-origin-validation-signaling-00 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 to IETF 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), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 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 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on October 28, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 78 2. Origin Validation State Extended Community . . . . . . . . . . 4 79 3. Changes to the BGP Decision Process . . . . . . . . . . . . . . 5 80 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 5 81 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 90 1. Introduction 92 As part of the origination AS validation process, it can be desirable 93 to automatically consider the validation state of routes in the BGP 94 decision process. The purpose of this document is to provide a 95 specification for doing so. The document defines a new BGP opaque 96 extended community to carry the validation state inside an autonomous 97 system to influence the decision process of the IBGP speakers. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. Origin Validation State Extended Community 107 The origin validation state extended community is an opaque extended 108 community [RFC4360] with the following encoding: 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | 0x43 | TBD | Reserved | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Reserved |validationstate| 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 The value of the high-order octet of the extended Type Field is 0x43, 119 which indicates it is non-transitive. The value of the low-order 120 octet of the extended type field for this community is TBD. The last 121 octet of the extended community encodes the route's validation 122 state([I-D.pmohapat-sidr-pfx-validate]. It can assume the following 123 values: 125 +-------+-----------------------------+ 126 | Value | Meaning | 127 +-------+-----------------------------+ 128 | 0 | Lookup result = "valid" | 129 | 1 | Lookup result = "not found" | 130 | 2 | Lookup result = "invalid" | 131 +-------+-----------------------------+ 133 If the router is configured to support the extensions defined in this 134 draft, it SHOULD attach the origin validation state extended 135 community to BGP UPDATE messages sent to IBGP peers by mapping the 136 computed validation state in the last octet of the extended 137 community. Similarly on the receiving IBGP speakers, the validation 138 state of an IBGP route SHOULD be derived directly from the last octet 139 of the extended community, if present. Note that routers do not 140 perform prefix origin validation (compute the validation state as 141 defined in [I-D.pmohapat-sidr-pfx-validate]) for IBGP learnt routes. 143 Since the extended community is defined to be non-transitive, it MUST 144 not be attached while advertising routes to EBGP peers. 145 Additionally, if it is present in an UPDATE message received from an 146 EBGP peer, the router MUST remove the origin validation state 147 extended community before parsing rest of the message. 149 3. Changes to the BGP Decision Process 151 If a BGP router supports prefix origin validation and is configured 152 for the extensions defined in this document, the validation step MUST 153 be performed prior to any of the steps defined in the decision 154 process of [RFC4271]. The validation step is stated as follows: 156 When comparing a pair of routes for a BGP destination, the route 157 with the lowest "validation state" value is preferred. 159 In all other respects, the decision process remains unchanged. 161 3.1. Policy Control 163 It MUST be possible to enable or disable the validation step as 164 defined in Section 3 through configuration. The default SHOULD be 165 for the validation step to be disabled. 167 4. Deployment Considerations 169 In deployment scenarios where not all the speakers in an autonomous 170 system are upgraded to support the extensions defined in this 171 document, it is necessary to define policies that match on the origin 172 validation extended community and set another BGP attribute 173 [I-D.pmohapat-sidr-pfx-validate] that influences the best path 174 selection the same way as what would have been enabled by an 175 implementation of this extension. 177 5. Acknowledgements 178 6. IANA Considerations 180 IANA shall assign a new value from the "BGP Opaque Extended 181 Community" type registry from the non-transitive range, to be called 182 "BGP Origin Validation State Extended Community". 184 7. Security Considerations 186 8. References 188 8.1. Normative References 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, March 1997. 193 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 194 Protocol 4 (BGP-4)", RFC 4271, January 2006. 196 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 197 Communities Attribute", RFC 4360, February 2006. 199 8.2. Informative References 201 [I-D.pmohapat-sidr-pfx-validate] 202 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 203 Austein, "BGP Prefix Origin Validation", 204 draft-pmohapat-sidr-pfx-validate-06 (work in progress), 205 April 2010. 207 Authors' Addresses 209 Pradosh Mohapatra 210 Cisco Systems 211 170 W. Tasman Drive 212 San Jose, CA 95134 213 USA 215 Email: pmohapat@cisco.com 216 Keyur Patel 217 Cisco Systems 218 170 W. Tasman Drive 219 San Jose, CA 95134 220 USA 222 Email: keyupate@cisco.com 224 John Scudder 225 Juniper Networks 226 1194 N. Mathilda Ave 227 Sunnyvale, CA 94089 228 USA 230 Email: jgs@juniper.net 232 David Ward 233 Juniper Networks 234 1194 N. Mathilda Ave 235 Sunnyvale, CA 94089 236 USA 238 Email: dward@juniper.net 240 Randy Bush 241 Internet Initiative Japan, Inc. 242 5147 Crystal Springs 243 Bainbridge Island, Washington 98110 244 USA 246 Email: randy@psg.com