idnits 2.17.1 draft-lapukhov-bgp-opaque-signaling-03.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 == 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 'SHOULD not' in this paragraph: This document introduces a new AFI known as a "BGP Opaque Data AFI" with the actual value to be assigned by IANA. The purpose of this AFI is to exchange opaque information within a BGP network. The propagation scope is to be controlled by the usual means of BGP policy, except that the policy SHOULD not match on NLRI information in any form other than an opaque string. -- The document date (October 31, 2016) is 2705 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) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-36) exists of draft-ietf-idr-bgp-extended-messages-13 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing P. Lapukhov 3 Internet-Draft Facebook 4 Intended status: Standards Track E. Aries, Ed. 5 Expires: May 4, 2017 P. Marques 6 Juniper Networks 7 E. Nkposong 8 Salesforce.com Inc 9 October 31, 2016 11 Use of BGP for Opaque Signaling 12 draft-lapukhov-bgp-opaque-signaling-03 14 Abstract 16 Border Gateway Protocol with multi-protocol extensions (MP-BGP) 17 enables the use of the protocol for dissemination of virtually any 18 information. This document proposes a new Address Family/Subsequent 19 Address Family to be used for distribution of opaque data. This 20 functionality is intended to be used by applications other than BGP 21 for exchange of their own data on top of BGP mesh. The structure of 22 such data SHOULD NOT be interpreted by the regular BGP speakers, 23 rather the goal is to use BGP purely as a convenient and scalable 24 communication system. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 4, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. BGP Opaque Data AFI . . . . . . . . . . . . . . . . . . . . . 3 68 3. BGP Key-Value SAFI . . . . . . . . . . . . . . . . . . . . . 3 69 4. BGP VPN Key-Value SAFI . . . . . . . . . . . . . . . . . . . 3 70 5. Capability Advertisement . . . . . . . . . . . . . . . . . . 3 71 6. Disseminating Key-Value bindings . . . . . . . . . . . . . . 3 72 6.1. Publishing a Key-Value binding . . . . . . . . . . . . . 4 73 6.2. Removing a Key-Value binding . . . . . . . . . . . . . . 5 74 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 75 7.1. Propagating multiple values for the same key . . . . . . 6 76 7.2. Automated filtering . . . . . . . . . . . . . . . . . . . 6 77 7.3. Filtering via policy . . . . . . . . . . . . . . . . . . 6 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 83 11.2. Informative References . . . . . . . . . . . . . . . . . 7 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 Implementation of Multiprotocol Extensions for BGP-4 [RFC4760] gives 89 the ability to pass arbitrary data in BGP protocol messages. This 90 capability has been leveraged by many for dissemination of non- 91 routing related information over BGP (e.g. "Dissemination of Flow 92 Specification Rules" [RFC5575] as well as "North-Bound Distribution 93 of Link-State and TE Information using BGP" 94 [I-D.ietf-idr-ls-distribution]). However, there has been no channel 95 defined explicitly to disseminate data with arbitrary payload. The 96 intended use case is for applications other than BGP to leverage the 97 protocol machinery for distribution (broadcasting) of their own state 98 in the network domain. Publishers and consumers will use BGP UPDATE 99 messages over TCP transport to submit and receive opaque data. It is 100 up to the BGP implementation to provide a custom API for message 101 producers or consumers, if needed. 103 2. BGP Opaque Data AFI 105 This document introduces a new AFI known as a "BGP Opaque Data AFI" 106 with the actual value to be assigned by IANA. The purpose of this 107 AFI is to exchange opaque information within a BGP network. The 108 propagation scope is to be controlled by the usual means of BGP 109 policy, except that the policy SHOULD not match on NLRI information 110 in any form other than an opaque string. 112 3. BGP Key-Value SAFI 114 This document introduces a new SAFI known as "BGP Key-Value SAFI" 115 with the actual value to be assigned by IANA. The purpose of this 116 SAFI is exchange of opaque information structured as Key-Value 117 binding. 119 4. BGP VPN Key-Value SAFI 121 This document introduces a new SAFI known as a "BGP VPN Key-Value 122 SAFI" with the actual value to be assigned by IANA. The purpose of 123 this SAFI is exchange of opaque information structured as a Key-Value 124 binding over service provider backbone providing Virtual Private 125 Networks as a service. The [RFC4364] defines a method and procedures 126 for implementing VPNs using BGP as a control plane. All the 127 procedures of [RFC4364] apply to the BGP VPN Key-Value SAFI. Under 128 this SAFI, the NLRI for the opaque information has the mandatory 8 129 bytes of Route Distinguisher at the beginning of the NLRI field. 131 5. Capability Advertisement 133 A BGP speaker that wishes to exchange Opaque Data MUST use the 134 Multiprotocol Extensions Capability Code, as defined in [RFC4760], to 135 advertise the corresponding AFI/SAFI pair. 137 6. Disseminating Key-Value bindings 139 This document proposes a distributed, eventually consistent Key-Value 140 store on top of existing BGP protocol transport mechanism. The "Key" 141 and "Value" portions are to be encoded as the NLRI part of 142 MP_REACH_NLRI attribute. 144 o Publishers advertise keys along with associated values into the 145 routing domain. The BGP network disseminates that state by 146 propagating the encoded data following regular BGP protocol 147 operations. 149 o Consumers receive the information via BGP protocol UPDATE 150 messages. Only publishers and consumers of the opaque data are 151 supposed to interpret its contents. The rest of the BGP network 152 acts merely as a dissemination system. 154 Multiple publishers can advertise the same key bound to different 155 values. Only the "Key" part of MP_REACH_NLRI filed MUST be used to 156 differentiate unique advertisements in such case. It is also 157 possible for the advertised binding to have the same Key-Value pairs, 158 but differ in some other BGP attributes. In that case, the BGP 159 implementation MUST follow the regular best-path selection logic to 160 prevent duplicate information in the network. A consumer will 161 receive the value created by the publisher "closest" in terms of BGP 162 best-path selection logic, based on the policies that exist in the 163 routing domain. This document does not propose methods to achieve 164 strong global consensus for all published values of a given key, as 165 it's generally impossible in eventually consistent data distribution 166 systems. 168 6.1. Publishing a Key-Value binding 170 The encoding scheme proposed below follows the semantics of a Key- 171 Value binding. The "Key" and "Value" are stored in the NLRI section 172 of the MP_REACH_NLRI attribute, as shown on Figure 1. 174 +---------------------------------------------------------+ 175 | Address Family Identifier (2 octets) | 176 +---------------------------------------------------------+ 177 | Subsequent Address Family Identifier (1 octet) | 178 +---------------------------------------------------------+ 179 | Length of Next Hop Address (1 octet), must be zero | 180 +---------------------------------------------------------+ 181 | Reserved (1 octet), must be zero | 182 +---------------------------------------------------------+ 183 | Opaque Key Length (2 octets) | 184 +---------------------------------------------------------+ 185 | Opaque Key Data (variable) | 186 +---------------------------------------------------------+ 187 | Opaque Value Data (variable) | 188 +---------------------------------------------------------+ 190 Figure 1: MP_REACH_NLRI Layout 192 o The AFI/SAFI values are to be allocated by IANA. 194 o Length of Next Hop Address: must be zero, indicating empty next- 195 hop. 197 o Opaque Key Length: identifies the size of the Key field in octets, 198 an unsigned integer value. The field MUST have a value of at 199 least one octet under the Key-Value SAFI and at least 9 octets 200 under the VPN Key-Value SAFI. Violating this requirement MUST 201 cause the receiver to ignore the advertised Key-Value binding. 203 o Opaque Key Data: the byte string representing the opaque key 204 contents. 206 o Opaque Value Data: The length of this field is determined by 207 subtracting the length of all previous fields from the total 208 length of MP_REACH_NLRI attribute. This field MAY be empty. 210 The maximum size of the Opaque "Key" and "Value" fields together is 211 limited by the BGP UPDATE message size. With the default BGP 212 protocol implementation is may not exceed 4096 octets (see [RFC4271] 213 Section 4). However, if [I-D.ietf-idr-bgp-extended-messages] is 214 implemented, the UPDATE message size could be as large as 65536 215 octets. 217 6.2. Removing a Key-Value binding 219 The removal procedure follows the regular MP-BGP route withdrawal, 220 using the MP_UNREACH_NLRI attribute. This section defines the 221 attribute structure for the new AFI/SAFI. 223 The specific MP_UNREACH_NLRI format is shown on Figure 2. This 224 message instructs the receiving BGP speaker to delete the N bindings 225 corresponding to Key 1, Key 2 ... Key N if the keys have been 226 previously learned from the withdrawing speaker. If any of the keys 227 could not be found in the LocRIB or has not been previously received 228 from the withdrawing BGP peer, such key removal request MUST be 229 ignored and the event MAY be logged. For the Key-Value SAFI, each 230 key length field must have the value of at least "1". For the VPN 231 Key-Value SAFI, each key length must be at least 9 octets long. 232 Violation of of these constraints MUST cause the receiver of the 233 UPDATE message to ignore the corresponding key withdrawal. 235 +---------------------------------------------------------+ 236 | Address Family Identifier (2 octets) | 237 +---------------------------------------------------------+ 238 | Subsequent Address Family Identifier (1 octet) | 239 +---------------------------------------------------------+ 240 | Opaque Key 1 Length (1 octet) | 241 +---------------------------------------------------------+ 242 | Opaque Key 1 Data (variable) | 243 +---------------------------------------------------------+ 244 ~ ~ 245 | Opaque Key N Length (1 octet) | 246 +---------------------------------------------------------+ 247 | Opaque Key N Data (variable) | 248 +---------------------------------------------------------+ 250 Figure 2: MP_UNREACH_NLRI attribute layout 252 7. Manageability Considerations 254 7.1. Propagating multiple values for the same key 256 It is possible to propagate multiple values associated with the same 257 key using the Add-Path extension defined in [I-D.ietf-idr-add-paths]. 258 However, this document recommends that instead unique key values 259 SHOULD be used for this purpose. It is up to the consumers and 260 publishers of the opaque data to settle on single unique value using 261 some kind of consensus protocol. 263 As a recommendation, the originators of key-value pairs may use the 264 origin ASN and the IPv4 or IPv6 address assigned to the originating 265 BGP speaker to create a unique key prefix. Alternatively, UUIDs 266 could be used to generate the unique key names, see [RFC4122] 268 7.2. Automated filtering 270 One can leverage mechanics described in [RFC4684] and use the route- 271 target extended community attribute to identify "channels" where key- 272 value bindings are published. The consumers would signal their 273 interest in particular "channel" by advertising the corresponding 274 router-target membership. The publications then need to carry the 275 router-target extended community attribute to restrict information 276 propagation. 278 7.3. Filtering via policy 280 Ad-doc message filtering could be implemented using BGP standard (see 281 [RFC4271]) or extended community attributes (see [RFC4360]). The 282 semantic of these attributes is to determined by the policy and 283 publishers/consumers. Filtering could be done locally on receiving 284 BGP speaker, or on remote BGP speaker, by using outbound route 285 filtering feature defined in [RFC5291]. 287 8. IANA Considerations 289 For the purpose of this work, IANA would be asked to allocate values 290 for the new AFI and SAFIs. 292 9. Security Considerations 294 This document does not introduce any changes in terms of BGP 295 security. The usual set of issues that arise from running multiple 296 AFI/SAFI's over single BGP session would apply in this case. 297 Additional concerns may be raised due to increase of the volume and 298 rate of change of the information distributed by means of opaque 299 signaling. 301 10. Acknowledgements 303 Keyur Patel provided useful feedback and suggested a practical 304 implementation of unique key semantic and support for VPN Key-Value 305 SAFI. 307 11. References 309 11.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 317 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 318 DOI 10.17487/RFC4271, January 2006, 319 . 321 11.2. Informative References 323 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 324 Unique IDentifier (UUID) URN Namespace", RFC 4122, 325 DOI 10.17487/RFC4122, July 2005, 326 . 328 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 329 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 330 February 2006, . 332 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 333 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 334 2006, . 336 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 337 R., Patel, K., and J. Guichard, "Constrained Route 338 Distribution for Border Gateway Protocol/MultiProtocol 339 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 340 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 341 November 2006, . 343 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 344 "Multiprotocol Extensions for BGP-4", RFC 4760, 345 DOI 10.17487/RFC4760, January 2007, 346 . 348 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 349 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 350 August 2008, . 352 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 353 and D. McPherson, "Dissemination of Flow Specification 354 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 355 . 357 [I-D.ietf-idr-add-paths] 358 Walton, D., Retana, A., Chen, E., and J. Scudder, 359 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 360 add-paths-15 (work in progress), May 2016. 362 [I-D.ietf-idr-ls-distribution] 363 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 364 Ray, "North-Bound Distribution of Link-State and TE 365 Information using BGP", draft-ietf-idr-ls-distribution-13 366 (work in progress), October 2015. 368 [I-D.ietf-idr-bgp-extended-messages] 369 Bush, R., Patel, K., and D. Ward, "Extended Message 370 support for BGP", draft-ietf-idr-bgp-extended-messages-13 371 (work in progress), June 2016. 373 Authors' Addresses 374 Petr Lapukhov 375 Facebook 376 1 Hacker Way 377 Menlo Park, CA 94025 378 US 380 Email: petr@fb.com 382 Ebben Aries (editor) 383 Juniper Networks 384 1133 Innovation Way 385 Sunnyvale, CA 94089 386 US 388 Email: exa@juniper.net 390 Pedro Marques 391 Juniper Networks 392 1194 N. Mathilda Ave 393 Sunnyvale, CA 94089 394 US 396 Email: roque@juniper.net 398 Edet Nkposong 399 Salesforce.com Inc 400 The Landmark @ One Market, ST 300 401 San Francisco, CA 94105 402 US 404 Email: enkposong@salesforce.com