idnits 2.17.00 (12 Aug 2021) /tmp/idnits17654/draft-keyupate-bgp-services-02.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 (April 26, 2013) is 3305 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) == Missing Reference: 'ADDPATHS' is mentioned on line 364, but not defined == Unused Reference: 'RFC3392' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC4486' is defined on line 511, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1998 ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K.P. Patel 3 Internet-Draft J.M. Medved 4 Intended status: Standards Track R.F. Fernando 5 Expires: October 28, 2013 B.P. Pithawala 6 Cisco Systems 7 April 26, 2013 9 Service Advertisement using BGP 10 draft-keyupate-bgp-services-02.txt 12 Abstract 14 A variety of services, such as NATs, firewalls, or caches, can be 15 embedded in a service provider network or instantiated in data 16 centers attached to the network. This document proposes extensions 17 to BGP that facilitate discovery of such service instances by 18 interested clients and allows dissemination of service information, 19 such as services capabilities or capacities, thoughtout the network 20 domain. The proposed extensions allow for optimal routing of 21 requests to service instances that can optimally serve them. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 28, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 71 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Service Advertisement & Discovery . . . . . . . . . . . . . . 5 74 2.1. The Service Advertisement Attribute . . . . . . . . . . . 5 75 3. Distribution of Service Data . . . . . . . . . . . . . . . . 6 76 3.1. Capability Advertisement for Service AFI . . . . . . . . 6 77 3.2. BGP Service AFI . . . . . . . . . . . . . . . . . . . . . 6 78 3.3. NLRI Format for Service AFI . . . . . . . . . . . . . . . 7 79 3.4. The Service Attribute . . . . . . . . . . . . . . . . . . 8 80 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.1. Announcing BGP Service Discovery Attribute . . . . . . . 8 82 4.2. BGP Service AFI . . . . . . . . . . . . . . . . . . . . . 8 83 5. Service Example . . . . . . . . . . . . . . . . . . . . . . . 9 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 9.2. Informative References . . . . . . . . . . . . . . . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 The current BGP specification does NOT provide any generic mechanism 95 to advertise service instances within a BGP enabled network. The 96 current BGP specification also does NOT provide a mechanism to carry 97 opaque service data within a BGP enabled network. This draft defines 98 several extensions to BGP that allows both the advertisement and the 99 discovery of service instances and the distribution of service 100 related data within a BGP network. 102 Service advertisement and discovery is facilitated by distributing 103 Service Advertiser location information throughout the network. This 104 document proposes a new optional transitive attribute - the Service 105 Advertisement Attribute that carries addresses of BGP Speakers, 106 thereby facilitating the service advertisements and service 107 discovery. Entities interested in receiving service information will 108 peer with one or more service-advertising BGP Speakers and receive 109 service data directly from them. 111 This draft also defines a new BGP Capability known as BGP Service AFI 112 Capability, a new BGP AFI and its NLRI format to carry opaque Service 113 data within a BGP enabled network. BGP Service AFI leaverages 114 existing BGP machninery of message annoucements, processing of 115 received messages, loop detection, policy application and other vital 116 protocol framework to transport Service information. Routers enabled 117 with Service AFI are expected to store Service information possibly 118 as an opaque data. 120 In addition to the service information discovery and dissemination 121 mechanism, Pub/Sub APIs MAY be required for registration of service 122 instances with the network entities. The definition of such Pub/Sub 123 APIs are outside the scope of this document. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 1.2. Terminology 133 This document uses the following terminology: 135 Service Instance: A Service application running on an end device or 136 on a network device. Service applications are bloadly classified 137 into two categories: Network Services and Application Services. 139 Service consumer: An end device or a network device that is a 140 interested in a particular Service. 142 Gateway: An network device that is responsible for doing a service 143 conversion across different protocols. 145 Originator: An end device or a network device originating a 146 particular service. 148 1.3. Overview 150 In today's networks, both the services provided in the network (NATs, 151 Firewalls, etc.) and the service overlays (services provided in 152 enterprise or cloud data centers) are dynamic in nature. New service 153 instances are instantiated on demand, instances that are not 154 sufficiently utilized are deleted and their resources are redeployed; 155 load and traffic patterns change frequently and abruptly; more and 156 more service consumers are mobile. A service consumer (or its proxy, 157 such as a service router) needs to know which services it can reach 158 and their location. To optimize the usage of the underlying network 159 and the service overlay, a service consumer needs to know where to 160 find service instances and what are capacities and capabilities of 161 each service instance. 163 BGP provides a transport to distribute service information for 164 several reasons: 166 o Scalability, performance and ubiquitous deployment in service 167 providers networks 169 o It can be used to distribute information within an AS domain or 170 between AS domains 172 o Leverage its security 174 o Rich policy capabilities allow the operator to control the 175 distribution of service information 177 +----------+ +----------+ +----------+ +----------+ 178 | Service | | Service | | Service | | Service | 179 | Provider | | Provider | | Consumer | | Consumer | 180 +----+-----+ +----+-----+ +----------+ +----------+ 181 | | ^ ^ 182 | V | | 183 | +---------+ +---------+ | 184 | | Gateway | | Gateway | | 185 | +---------+ +---------+ | 186 | | ^ | 187 V V _______ | | 188 +-----------------+ / \ +-----------------+ 189 | BGP Speaker |------>* Network *------>| BGP Speaker | 190 +-----------------+ \_______/ +-----------------+ 192 Figure 1: Service discovery and metadata exchange 194 Figure 1 shows a typical service network where services consumers 195 interact with each other over a network. As shown in the figure, a 196 Service Provider may inject service information into BGP either 197 directly or through a Gateway. BGP then distributes the Service 198 information within its network. Service information may also be 199 distributed across the AS domains. A Service consumer receives 200 Information about available services either directly by listening to 201 BGP updates or through a Gateway. Gateways may provide different 202 APIs to Service Providers/Consumers, for example ReST, XMPP, or 203 Websockets. 205 A Gateway translates between an application-friendly data format / 206 API on the Service Provider/Consumer Side, and a BGP-specific format 207 on the BGP Speaker side. The BGP-specific format would use BGP 208 protocol (i.e the Gaetway appears as a peer to the BGP Speaker) or an 209 API that can inject/retrieve data directly from BGP internal 210 databases, such as IRS. 212 2. Service Advertisement & Discovery 214 2.1. The Service Advertisement Attribute 216 The Service Advertisement attribute is a new BGP optional transitive 217 attribute. The attribute type code for the Service Advertisement 218 attribute is to be assigned by IANA. The value field of the Service 219 Advertisement attribute is defined as set of one or more Service 220 Tuples. 222 A Service Tuple within the Service Advertisement Attribute is defined 223 as follows: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Service Type ~ 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 ~ Service Type (Cont'd) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Orig-ID Type | Orig-ID Len | Originator-ID ~ 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 ~ Originator-ID ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: Service Tuple format 239 The fields are as follows: 241 Service Type: Eight octets encoding the Service Type. The Service 242 Type code point space will have to be maintained by IANA. Only 243 type 1 is defined in this document. Service ID from 4294967296 244 onwards are reserved for private use only. 246 Originator-ID Type: One octet encoding the Originator-ID Type. Type 247 value of 0 indicates an IPv4 address type, Type value of 1 248 indicates an IPv6 address type, and Type value of 2 indicates an 249 AS number type. 251 Originator-ID Length: One octet encoding the Originator-ID address 252 length. Orignator-ID is not present in the Service Tuple if the 253 Originator-ID Length is 0. 255 Originator-ID: Optional, contains the IP address of the router 256 Originating the Service Tuple. If the advertising router's IP 257 address is not present, then the Originator of the Service 258 Advertisement attribute is the first AS aka rightmost AS in the 259 final segment of an ASPATH attribute if that segment is of type 260 AS_SEQUENCE, or the distinguished value "NONE" if the final 261 segment of the AS_PATH attribute is of any type other than 262 AS_SEQUENCE. Originator ID length of 4 octets indicate an IPv4 263 Address and 16 octets indicates an IPv6 address 265 The service attribute applies to all prefixes carried in an UPDATE 266 message - either in IPv4 NLRI or in MP_REACH/MP_UNREACH attributes. 268 3. Distribution of Service Data 270 3.1. Capability Advertisement for Service AFI 272 The BGP Service AFI Capability is a new BGP capability, that can be 273 used by a BGP speaker to indicate its support for BGP Service AFI 274 Advertisements. A BGP speaker willing to exchange this capability 275 MUST advertise this information in the OPEN message using BGP 276 Capability code 1 [RFC4760]. The AFI value is set to BGP Service AFI 277 value to be assigned by IANA. The SAFI value is set to UNICAST 278 value. 280 3.2. BGP Service AFI 281 This document introduces a new AFI known as a BGP Service AFI with a 282 value to be assigned by IANA. The purpose of this AFI would be to 283 exchange Service specific information within a BGP network. The SAFI 284 value is set to UNICAST value as defined in IANA SAFI registry. 286 3.3. NLRI Format for Service AFI 288 BGP Service AFI NLRI is advertised in BGP UPDATE messages using the 289 MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The AFI used 290 to identify this NRLI is BGP Service AFI with a value to be assigned 291 by IANA. The SAFI value is set to UNICAST value as defined in IANA 292 SAFI registry. 294 The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as 295 an IPv4 address whenever the length of the Next Hop address is 4 296 octets, and as an IPv6 address whenever the length of the Next Hop 297 address is 16 octets. 299 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 300 with the maximum length of 276 octets. The NLRI field of the 301 MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as a 1-octet NLRI length 302 field in bytes followed by a variable-length NLRI value. The NLRI 303 length is expressed in octets. 305 +--------------------------------+ 306 | length (1 octet) | 307 +--------------------------------+ 308 | NLRI value (variable) | 309 +--------------------------------+ 311 Figure 3: Service NLRI 313 The Length field indicates the length of NLRI value in octets. 315 The NLRI Format is as follows: 317 +--------------------------------+ 318 | AS Number (4 octets) | 319 +--------------------------------+ 320 | Originator ID (16 octets) | 321 +--------------------------------+ 322 ~ Service ID ~ 323 ~ Variable (up to 227 Octets) ~ 324 +--------------------------------+ 326 Figure 4: Service NLRI format 328 The fields in the Service NLRI are as follows: 330 AS Number: Four octets encoding the AS Number of an Autonomous 331 System originating the prefix. The AS Number value will be the 332 value assigned by IANA. 334 Originator ID: 16 Octets encoding the Originator ID value. 336 Service ID: Upto 227 octets encoding the Service ID value. 338 3.4. The Service Attribute 340 The Service attribute is a new BGP optional transitive attribute. 341 The attribute type code for the Service attribute is to be assigned 342 by IANA. The Service attribute carries BGP Service AFI NLRI specific 343 information. The value field of the Service attribute contains 344 service specific data opaque to BGP. 346 4. Operation 348 4.1. Announcing BGP Service Discovery Attribute 350 The Service Discovery attribute is used to announce/withdraw new 351 Service instances within a network. The Service Discovery attribute 352 is a new optional transitive attribute that can be applied to any AFI 353 /SAFI within BGP; thereby facilitating service instance discovery on 354 an existing network. The attribute is not related to the AFI/SAFI to 355 which it is attached, and it does not impact the BGP selection 356 algorithm. The AFI/SAFI is used merely as a distribution mechanism 357 for Service Advertiser information carried in the attribute. 359 A BGP Speaker MUST aggregate all the Service attribute Tuple 360 information received from all the paths (including the non-bestpaths) 361 for a given NLRI and announce the aggregated Service information 362 along with the bestpath in case where all the BGP paths [ADDPATHS] 363 are not being announced. A BGP Speaker MUST announce BGP Service 364 attribute along with its own path whenever all the paths [ADDPATHS] 365 are announced. These rules ensure that Service Discovery attributes 366 always get announced within a given network. 368 Each Service Announcement attribute tuple consist of an optional 369 Originator-ID value. If this value is present, then a Service Tuple 370 information is considered as incomplete if it does not contain a 371 valid Originator-ID address or an Origin AS number. In such 372 conditions, the received Service Tuple information maybe be ignored 373 with an appropriate error logging. 375 4.2. BGP Service AFI 376 BGP Service AFI is a new AFI used to carry Opaque Service 377 information. The opaque Service data is carried within BGP using the 378 BGP Service Attribute that is attached to a BGP Service AFI NLRIs. 379 BGP Speakers configured to exchange data over the BGP Service AFI are 380 required to store and forward the opaque Service level information. 381 A standard BGP refreshing mechanisms [RFC2918] could be used to 382 refresh the information hop-by-hop whenever required. The scope of 383 announcing opaque Service data could be control using BGP Communities 384 defined in [RFC1998] or using BGP Extended Communities defined in 385 [RFC4360]. 387 BGP Service AFI MAY use multisession [I-D.ietf-idr-bgp-multisession] 388 to have a separate session to transport its opaque data and thereby 389 not affect the performance of existing routing AFI/SAFIs within BGP. 391 5. Service Example 393 It is assumed that service-specific attributes and NLRIs will be 394 defined in their own documents. Each service needs to advertise its 395 reachability, capacities and capabilities. This section provides an 396 example of a service - a simple caching service. 398 It is assumed that the Service ID will be allocated by IANA for the 399 simple caching service. 401 The simple caching service will only advertise service availability 402 during service discovery using the Service Advertisement Attribute 403 (Section 2.1). A simple cache service instance is identified by its 404 IPv4 and IPv6 addresses. The Service ID in the Service NLRI (Figure 405 3) is defined as follows: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Service IPv4 address | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 | Service IPv6 Address | 414 | | 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 5: Service ID for simple cache service 420 A simple cache service instance advertises its capacities and 421 capabilities as TLVs in the service Attribute (Section 3.4). The TLV 422 data is opaque to the BGP speaker. The TLVs are as follows: 424 Load: Identifies the current load of the cache; the bigger the load, 425 the less prefered is this instance of the service. Load is an 426 interger in the range 0-100. which shows the percentage of the 427 capacity of the service instance is currently being used by 428 clients. 430 Supported media types: This TLVs lists all media types that can be 431 served from this cache instance. There is a sub-TLV for each 432 media type. 434 Protocols: This TLVs lists all protocol types that can be used to 435 serve content from this cache instance. There is a sub-TLV for 436 each protocol type. 438 Simple cache service instance advertisements are injected into BGP by 439 simple cache instances throguh a gateway or a proxy providing an XMPP 440 or RESTful API. Simple cache service instance advertisements are 441 received by a service router, which directs client requests to the 442 most appropriate instance of the cache. 444 6. IANA Considerations 446 This document requests a code point from the registry of Address 447 Family Numbers. 449 This document requests a code point from the BGP Path Attributes 450 registry. 452 This document requests creation of a new registry for service type 453 codepoints. Allocations within the registry will require 454 documentation of the proposed use of the allocated value and approval 455 by the Designated Expert assigned by the IESG (see [RFC5226]). 457 Note to RFC Editor: this section may be removed on publication as an 458 RFC. 460 7. Security Considerations 462 This extension to BGP does not change the underlying security issues 463 inherent in the existing [RFC4724] and [RFC4271] 465 8. Acknowledgements 467 The authors would like to thank Dave Ward and Stefano Previdi for the 468 review and comments. 470 9. References 471 9.1. Normative References 473 [I-D.ietf-idr-bgp-multisession] 474 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 475 BGP", draft-ietf-idr-bgp-multisession-07 (work in 476 progress), September 2012. 478 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 479 Community Attribute in Multi-home Routing", RFC 1998, 480 August 1996. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 486 September 2000. 488 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 489 with BGP-4", RFC 3392, November 2002. 491 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 492 Protocol 4 (BGP-4)", RFC 4271, January 2006. 494 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 495 Communities Attribute", RFC 4360, February 2006. 497 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 498 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 499 January 2007. 501 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 502 "Multiprotocol Extensions for BGP-4", RFC 4760, January 503 2007. 505 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 506 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 507 May 2008. 509 9.2. Informative References 511 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 512 Notification Message", RFC 4486, April 2006. 514 Authors' Addresses 516 Keyur Patel 517 Cisco Systems 518 170 W. Tasman Drive 519 San Jose, CA 95134 520 USA 522 Email: keyupate@cisco.com 524 Jan Medved 525 Cisco Systems 526 170 W. Tasman Drive 527 San Jose, CA 95134 528 USA 530 Email: jmedved@cisco.com 532 Rex Fernando 533 Cisco Systems 534 170 W. Tasman Drive 535 San Jose, CA 95134 536 USA 538 Email: bpithaw@cisco.com 540 Burjiz Pithawala 541 Cisco Systems 542 170 W. Tasman Drive 543 San Jose, CA 95134 544 USA 546 Email: bpithaw@cisco.com