idnits 2.17.1 draft-lapukhov-bgp-opaque-signaling-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC4760]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 106: '...s to exchange Opaque Data MUST use the...' RFC 2119 keyword, line 168: '...e implementation MUST ignore the adver...' RFC 2119 keyword, line 171: '...s. This portion SHOULD NOT be interpr...' RFC 2119 keyword, line 194: '...ts of this field MUST be set to zero, ...' RFC 2119 keyword, line 201: '... portion SHOULD NOT be interprete...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2014) is 3424 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 normative reference: RFC 2858 (Obsoleted by RFC 4760) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-10 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR P. Lapukhov 3 Internet-Draft E. Aries 4 Intended status: Standards Track Facebook 5 Expires: June 12, 2015 P. Marques 6 Contrail Systems 7 E. Nkposong 8 Microsoft Corporation 9 December 9, 2014 11 Use of BGP for opaque signaling 12 draft-lapukhov-bgp-opaque-signaling-00 14 Abstract 16 Border Gateway Protocol with multi-protocol extensions (MP-BGP) 17 [RFC4760] enables the use of the protocol for dissemination of 18 virtually any information. This document proposes a new Address 19 Family/Subsequent Address Family to be used for distribution of 20 opaque data. This functionality is intended to be used by 21 applications other than BGP for exchange of their own data on top of 22 BGP mesh. The structure of such data is not to be interpreted by the 23 regular BGP speakers, rather the goal is to use BGP purely as a 24 convenient and scalable communication system. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 12, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. BGP Opaque Data AFI . . . . . . . . . . . . . . . . . . . . . 3 62 3. BGP Key-Value SAFI . . . . . . . . . . . . . . . . . . . . . 3 63 4. Capability Advertisement . . . . . . . . . . . . . . . . . . 3 64 5. Disseminating Key-Value bindings . . . . . . . . . . . . . . 3 65 5.1. Publishing a Key-Value binding . . . . . . . . . . . . . 4 66 5.2. Removing a Key-Value binding . . . . . . . . . . . . . . 5 67 5.3. Propagating multiple values for the same key . . . . . . 6 68 6. Message filtering . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Automated filtering . . . . . . . . . . . . . . . . . . . 7 70 6.2. Filtering via policy . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 Implementation of Multiprotocol Extensions for BGP-4 [RFC4760] allows 80 to pass aribtrary data in BGP protocol messages. This capability has 81 been leveraged by many for dissemination of non-routing related 82 information over BGP (for example, see "Dissemination of Flow 83 Specification Rules" defined in [RFC5575]). However, there has been 84 no channel defined explicitly to disseminate data with arbitrary 85 opaque payload. The intended use case is for applications other than 86 BGP to leverage the protocol machinery for distribution of their own 87 state in the network domain. Publishers and consumers will use BGP 88 UPDATE messages to exhcnage opaque data. It is up to the BGP 89 implementation to provide a custom API for message producers or 90 consumers if needed. 92 2. BGP Opaque Data AFI 94 This document introduces a new AFI known as a "BGP Opaque Data AFI" 95 with the actual value to be assigned by IANA. The purpose of this 96 AFI is to exchange opaque information within a BGP network. 98 3. BGP Key-Value SAFI 100 This document introduces a new SAIF known as "BGP Key-Value SAFI". 101 The purpose of this SAFI is exchange of opaque information structured 102 as a Key-Value binding (advertisement). 104 4. Capability Advertisement 106 A BGP speaker that wishes to exchange Opaque Data MUST use the 107 Multiprotocol Extensions Capability Code, as defined in [RFC2858], to 108 advertise the corresponding AFI/SAFI pair. 110 5. Disseminating Key-Value bindings 112 This document proposes to implement a distributed, eventually 113 consistent Key-Value store on top of existing BGP protocol mechanics. 114 The proposal is for "Key" portion to be encoded as the NLRI part of 115 MP_REACH_NLRI attribute and "Value" encoded using a new optional 116 transitive attribute. 118 Publishers, acting as BGP speakers, advertise keys along with 119 associated values into the routing domain. The BGP network 120 synchronizes that state by propagating the encoded data following 121 regular BGP protocol operations. 123 Consumers, acting as BGP speakers, receive the information via BGP 124 protocol UPDATE messages. Only publishers and consumers of the 125 opaque data are supposed to interpret its contents - the rest of 126 the BGP network acts merely as a dissemination system. 128 Multiple publishers can advertise the same key (NLRI) associated with 129 different values. It is also possible for the advertised 130 associations to have the same Key-Value pairs but differ in there 131 other BGP attributes. In that case, BGP would follow the best-path 132 selection logic to prevent duplicate information in the network. A 133 consumer will receive the value created by the publisher "closest" in 134 terms of BGP best-path selection logic, based on the policies that 135 exist in the routing domain. This document does not propose any 136 method of achieving global consensus for all published values for a 137 given key. See section Section 5.3 that discusses the means of 138 propagating multiple values for the same key. 140 5.1. Publishing a Key-Value binding 142 The encoding scheme proposed below follows the semantics of a Key- 143 Value bindings. The "Key" is stored in the NLRI section of the 144 MP_REACH_NLRI attribute, as shown on Figure 1. 146 +---------------------------------------------------------+ 147 | AFI (2 octets) | 148 +---------------------------------------------------------+ 149 | SAFI (1 octet) | 150 +---------------------------------------------------------+ 151 | Length of Next Hop Address (1 octet), must be zero | 152 +---------------------------------------------------------+ 153 | Reserved (1 octet), must be zero | 154 +---------------------------------------------------------+ 155 | Opaque Key Length (1 octet) | 156 +---------------------------------------------------------+ 157 | Opaque Key Data (variable) | 158 +---------------------------------------------------------+ 160 Figure 1: MP_REACH_NLRI Layout 162 o The AFI/SAFI values are to be allocated by IANA. 164 o Length of Next Hop Address: must be zero, since no information is 165 encoded in the next-hop address field. 167 o Opaque Key Length: identifies the size of the Key field. If field 168 is set to zero, the implementation MUST ignore the advertisement. 170 o Opaque Key Data: the byte string representing the opaque key 171 contents. This portion SHOULD NOT be interpreted by BGP 172 implementation. 174 The "Value" portion of a published binding is to be encoded in a new 175 optional transitive attribute as shown on Figure 2: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type |0 0 0 0| Opaque Value Length | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 182 ~ ~ 183 | Opaque Value Data (variable) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 186 Figure 2: OPAQUE_VALUE attribute layout 188 o Type: Identifies the new OPAQUE_VALUE attribute, with the value to 189 be allocated by IANA. 191 o Opaque Value Length: Two octets encoding the total length of the 192 attribute in octets, including the Type and Length fields. The 193 length is encoded as an unsigned binary integer. The four most 194 significant bits of this field MUST be set to zero, due to the 195 limit imposed by maximum BGP message size. Note that the minimum 196 length is 3, indicating that no Opaque Value Data field is 197 present. Such binding, in presence of non-zero length key is 198 still valid, as it informs the consumers that the key "exists". 200 o Opaque Value Data: A field containing zero or more octets. This 201 portion SHOULD NOT be interpreted by BGP implementations. 203 Even when the OPAQUE_VALUE optional transitive attribute is not 204 present in BGP advertisement, the BGP implementation MUST still 205 retain Opaque Key (NLRI) in its LocRIB and propagate it further as 206 usual. This case is to be interpreted as an announcement of the key 207 existence. 209 5.2. Removing a Key-Value binding 211 The removal procedure follows the regular MP-BGP route withdrawal, 212 using the MP_UNREACH_NLRI attribute. This section defines the 213 attribute structure for the new AFI/SAFI. 215 The message shown on Figure 3 instructs the receiving BGP speaker to 216 delete the N bindings corresponding to Key 1, Key 2 ... Key N if the 217 keys have been previously learned from the withdrawing speaker. If 218 any of the Keys is not found in the LocRIB or has not been previously 219 received from the withdrawing BGP peer, such key removal request MUST 220 be ignored. 222 +---------------------------------------------------------+ 223 | AFI (2 octets) | 224 +---------------------------------------------------------+ 225 | SAFI (1 octet) | 226 +---------------------------------------------------------+ 227 | Opaque Key 1 Length (1 octet) | 228 +---------------------------------------------------------+ 229 | Opaque Key 1 Data (variable) | 230 +---------------------------------------------------------+ 231 ~ ~ 232 | Opaque Key N Length (1 octet) | 233 +---------------------------------------------------------+ 234 | Opaque Key N Data (variable) | 235 +---------------------------------------------------------+ 237 Figure 3: MP_UNREACH_NLRI attribute layout 239 5.3. Propagating multiple values for the same key 241 It is possible to propagate multiple values associated with the same 242 key using the Add-Path extension defined in [I-D.ietf-idr-add-paths]. 243 The values are differentiated by the Path Identifier field present in 244 the key. If the capability is negotiated between two BGP speakers, 245 the key encoding in NLRI field of MP_REACH_NLRI and MP_UNREACH_NLRI 246 attributes is extended to look as shown on Figure 4. The "Opaque Key 247 Length" and "Opaque Key Data" retain the same meaning as defined 248 previously. 250 +---------------------------------------------------------+ 251 | Path Identifier (4 octets) | 252 +---------------------------------------------------------+ 253 | Opaque Key Length (1 octet) | 254 +---------------------------------------------------------+ 255 | Opaque Key Data (variable) | 256 +---------------------------------------------------------+ 258 Figure 4: AddPath Encoding 260 The above defined encoding is to be used both with MP_REACH_NLRI and 261 MP_UNREACH_NLRI attributes. It is up to the implementation to decide 262 how many additional values to propagate with the key. 264 Note that the Add-Path extension could also be used to propagate the 265 same Key-Value pairs with different Path Identifiers, assuming that 266 other BGP attributes associated with the same NLRI are different. 268 6. Message filtering 270 Limiting the scope of opaque information flooding is an important 271 operational concern. BGP already has the mechanisms needed to 272 control this process, and these mechanisms are briefly reviewed 273 below. 275 6.1. Automated filtering 277 One can leverage mechanics presented in [RFC4684] and use the route- 278 target extended community attribute to identify "channels" where key- 279 value bindings are published. The consumers would signal their 280 interest in particular "channel" by advertising the corresponding 281 router-target membership. The publications then need to contain the 282 router-target extended community attribute to constrain information 283 propagation. 285 6.2. Filtering via policy 287 Ad-doc message filtering could be implemented using BGP standard (see 288 [RFC4271]) or extended community attributes (see [RFC4360]). The 289 semantic of these attributes is to determined by the policy and 290 publishers/consumers. Filtering could be done locally on receiving 291 speaker, or on remote speaker, by using outbound route filtering 292 feature defined in [RFC5291]. 294 7. IANA Considerations 296 For the purpose of this work, IANA would be asked to allocate values 297 for the new AFI and SAFI. 299 8. References 301 8.1. Normative References 303 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 304 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 306 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 307 Protocol 4 (BGP-4)", RFC 4271, January 2006. 309 8.2. Informative References 311 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 312 Communities Attribute", RFC 4360, February 2006. 314 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 315 R., Patel, K., and J. Guichard, "Constrained Route 316 Distribution for Border Gateway Protocol/MultiProtocol 317 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 318 Private Networks (VPNs)", RFC 4684, November 2006. 320 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 321 "Multiprotocol Extensions for BGP-4", RFC 4760, January 322 2007. 324 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 325 Capability for BGP-4", RFC 5291, August 2008. 327 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 328 and D. McPherson, "Dissemination of Flow Specification 329 Rules", RFC 5575, August 2009. 331 [I-D.ietf-idr-add-paths] 332 Walton, D., Retana, A., Chen, E., and J. Scudder, 333 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 334 add-paths-10 (work in progress), October 2014. 336 Authors' Addresses 338 Petr Lapukhov 339 Facebook 340 1 Hacker Way 341 Menlo Park, CA 94025 342 US 344 Email: petr@fb.com 346 Ebben Aries 347 Facebook 348 1 Hacker Way 349 Menlo Park, CA 94025 350 US 352 Email: exa@fb.com 353 Pedro Marques 354 Contrail Systems 355 440 N Wolfe Rd 356 Sunnyvale, CA 94085 357 US 359 Email: roque@contrailsystems.com 361 Edet Nkposong 362 Microsoft Corporation 363 1 Microsoft Way 364 Redmond, WA 98052 365 US 367 Email: edetn@microsoft.com