idnits 2.17.1 draft-ietf-idr-sla-exchange-07.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 == Line 230 has weird spacing: '...e Value varia...' -- The document date (February 4, 2016) is 2976 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) == Unused Reference: 'I-D.ietf-sidr-bgpsec-protocol' is defined on line 1218, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-09 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-14 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 7674 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Shah 3 Internet-Draft K. Patel 4 Intended status: Standards Track Cisco Systems 5 Expires: August 7, 2016 S. Bajaj 6 Juniper Network 7 L. Tomotaki 8 Verizon 9 M. Boucadair 10 Orange 11 February 4, 2016 13 Inter-domain SLA Exchange Attribute 14 draft-ietf-idr-sla-exchange-07.txt 16 Abstract 18 Network administrators typically enforce Quality of Service (QoS) 19 policies according to Service Level Agreement (SLA) with their 20 providers. The enforcement of such policies often relies upon 21 vendor-specific configuration language. Both learning of SLA, either 22 thru SLA documents or via some other out-of-band method, and 23 translating them to vendor specific configuration language is a 24 complex, often manual, process and prone to errors. 26 This document specifies an optional transitive attribute to signal 27 SLA parameters in-band, across administrative boundaries (considered 28 as Autonomous Systems (AS)), thus simplifying and facilitating some 29 of the complex provisioning tasks in situations where BGP is 30 available as a routing protocol. 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 August 7, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 4 69 3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 5 70 3.2. SLA SubType Value Field . . . . . . . . . . . . . . . . . 6 71 3.3. SLA-Content per Event Field . . . . . . . . . . . . . . . 8 72 3.3.1. Supported IPFIX values for Classifier Elements . . . 12 73 3.3.2. Traffic Class Service TLVs . . . . . . . . . . . . . 13 74 4. Originating SLA Notification . . . . . . . . . . . . . . . . 20 75 4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 20 76 4.1.1. SLA Advertisement for Point-to-Point Connection . . . 21 77 4.1.2. SLA Advertisement for Destination AS Multiple Hops 78 Away . . . . . . . . . . . . . . . . . . . . . . . . 21 79 5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . 22 80 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 22 81 5.2. SLA Attribute Handling at Receiver . . . . . . . . . . . 22 82 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 83 7. Traffic Class Mapping . . . . . . . . . . . . . . . . . . . . 23 84 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 24 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 90 12.2. Informative References . . . . . . . . . . . . . . . . . 28 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 93 1. Introduction 95 Typically there is a contractual Service Level Agreement (SLA) for 96 QoS established between a customer and a provider or between 97 providers [RFC7297]. This QoS SLA defines the nature of the various 98 traffic classes and services needed within each traffic class. The 99 contract may include full line-rate or sub line-rate without 100 additional traffic classes, or it may contain additional traffic 101 classes and service definitions for those traffic classes. Finer 102 granular traffic classes may be based on some standard code points 103 (e.g., based on DSCP (Differentiated Services Code Point)) or 104 specific set of prefixes. 106 Once the contractual QoS SLA is established, QoS SLA parameters are 107 enforced in some or all participating devices by deriving those 108 parameters into configuration information on respective devices. The 109 network administrator translates the QoS SLA to QoS policies using 110 router (vendor) specific provisioning language. In a multi-vendor 111 network, translating SLAs into technology-specific and vendor- 112 specific configuration requires the network administrator to consider 113 specific configuration of each vendor. There does not exist any 114 standard protocol to translate SLA agreements into technical clauses 115 and configurations and thus both the steps of out of band learning of 116 negotiated SLA and provisioning them in a vendor specific language 117 can be complex and error-prone. 119 SLA parameters may have to be exchanged through organizational 120 boundaries, thru SLA documents or via some other off-band method, to 121 an administrator provisioning actual devices. 123 For example, to provide voice services, the provider may negotiate 124 QoS parameters (like min/max rates) for such traffic classified under 125 the EF (Expedited Forwarding) codepoint in Diffserv-enabled [RFC2475] 126 networks. The Administrator at the CE (Customer Edge) not only will 127 have to know that provider's service for voice traffic is EF-based 128 but will also have to know how to implement DSCP EF classification 129 rule along with Low Latency Service, and possibly min/max rate 130 enforcement for the optimal use of bandwidth, as per vendor specific 131 provisioning language. 133 The Inter-domain exchange of QoS SLA exchange policy described in 134 this document does not require any specific method for the provider 135 in establishing SLAs. It only requires that the provider wishes to 136 send the QoS SLA policy via BGP UPDATE [RFC4271] messages from the 137 provider to a set of receivers (BGP peers) who will enact the policy. 138 In reaction to, a receiving router may translate that to relevant QoS 139 policy definition on the device. 141 This document defines a new optional transitive BGP QoS attribute 142 which has as one of its sub-types the SLA policy. The BGP speakers 143 of the originating AS send the BGP Attribute for prefixes this QoS 144 SLA Policy applies to in a BGP UPDATE message that will be 145 distributed to a list of destination ASes. The QoS SLA policy can be 146 for inbound traffic to the advertising AS or outbound traffic from 147 the advertising AS, or both. 149 The SLA negotiation and assurance is outside the scope of this 150 document. In the future, other sub-types of the QoS Attribute may 151 deal with QoS other than SLA Policy for traffic. 153 Protocols and data models are being created to standardize setting 154 routing configuration parameters within networks. YANG data models 155 [RFC6020] are being developed so that NETCONF ([RFC6241] or RESTConf 156 ([I-D.ietf-netconf-restconf]) can set these standardized in 157 configuration mechanisms. For ephemeral state, the I2RS protocol is 158 being developed to set ephemeral state. While these protocol provide 159 valid configuration within a domain or across domains, some providers 160 desire to exchange QoS parameters in-band utilizing BGP peering 161 relationships. This is similar to the distribution of Flow 162 Specification information via BGP peering relationships (see 163 [RFC5575] and [RFC7674]). 165 2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 3. QoS Attribute Definition 173 The QoS Attribute is an optional transitive attribute (TBD - 174 attribute code to be assigned by IANA). SLA is defined as one of the 175 sub-types in the QoS attribute. The QoS attribute is only applicable 176 to the NLRIs advertised in the BGP UPDATE message this attribute is 177 included in. 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Attr flag | Attr type QoS | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 184 ~ ~ 185 | QoS Attr length/Value | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 188 Attribute flags 189 highest order bit (bit 0) - 190 MUST be set to 1, since this is an optional attribute 192 2nd higher order bit (bit 1) - 193 MUST be set to 1, since this is a transitive attribute 195 Figure 1 - QoS BGP attribute 197 3.1. SLA, QoS attribute sub-type, Definition 199 The value field of the QoS Attribute contains the following: 201 QoS Attribute flags, and 203 Tuple of (SLA sub-type, length, value). 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | QoS Attr flags| subType | subtype Length | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 ~ ~ 211 | SubType-Value | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.........................+ 214 Figure 2 - Format of BGP QoS Attribute 216 QoS Attr flags 1 octet. All the bits are currently un-used. The 217 space is provided for future use. All bits MUST be set to zero 218 when sent. The values (0x01-0xFF) are reserved, and MUST be 219 ignored when received. 221 SubType 1 octet field with the following values: 223 0x00 = reserved 224 0x01 = SLA 226 0x02 - 0x0f = reserved for future use (Standards Action) 228 SubType length - 2 octet field with length of sub-type value. 230 SubType Value variable length field containing information about: 231 sender and receiver(s), and SLA parameters described in 232 Section 3.2. 234 3.2. SLA SubType Value Field 236 The format of SubType Value field is shown in Figure 3. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | 32-bit Source AS (Advertiser) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | 32-bit Destination AS count | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | variable list of destination AS | 246 ~ .... ~ 247 | .... | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Event | SLA id | SLA length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | SLA-Content per SLA Event | 252 ~ ~ 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 3 - The format of SLA SubType of the BGP QoS attribute 258 Source AS: 32-bit source AS number. This is the AS that is 259 advertising SLA 261 0 = ignore Source and Destination AS list from this value field 263 Note that AS = 0, used in message outside of QoS attribute, is 264 illegal in normal BGP operations. AS = 0 inside the QoS 265 attribute may be used simply as a flag to indicate to the 266 receiver to ignore Source and Destination AS list from inside 267 the QoS attribute. 269 Destination AS count: 32-bit destination AS count to take variable 270 length AS list. This count has no functional value when Source AS 271 is 0. 273 0 = QoS attribute is relevant to every receiver of the message 275 Destination AS list: 277 32-bit destination AS number 279 .... 281 .... [as many as AS count] 283 SLA Event: 285 4-bits with values 287 0x0 = reserved 289 0x1 = ADVERTISE 291 0x2 to 0xf - Reserved for future use 293 SLA Id: A 16-bit field containing identifier which is unique in 294 scope of source AS 296 The significance of an SLA identifier is in the context of the 297 source that is advertising SLA parameters. The SLA identifier 298 is not globally unique but it MUST be unique within the source 299 AS (advertiser). 301 If the advertised SLA id is different from earlier advertised 302 one, for the same prefix, previous SLA content MUST be replaced 303 with the new advertised one. 305 The SLA ID applies aggregate for all the traffic to prefixes 306 for a given AFI/SAFI that share same source AS and SLA id. 308 SLA Length: A 12-bit field indicating the length of SLA-Content. 309 The SLA-content is optional for each advertised SLA id. If the 310 SLA-content field does not exist, the SLA length field value is 311 zero. 313 SLA-Content per SLA Event: A variable length field (optional field). 315 If SLA field exists, it follows the format described in 316 Section 3.3. 318 If the SLA-Content field does not exist in a BGP UPDATE message 319 that contains the QoS attribute with an SLA Sub-type, then 320 receiver MUST inherit the previously advertised SLA content for 321 the same SLA id from the same Source AS. 323 If there does not exist any prior SLA to relate to the 324 advertised SLA id, then receiver can ignore the SLA 325 advertisement and process the rest of the BGP message. 327 The lack of a valid prior SLA-Content field does not make this 328 attribute invalid, so the attribute MUST be forwarded as a 329 valid BGP optional transitive attribute. 331 3.3. SLA-Content per Event Field 333 The only event described below is ADVERTISE. The format of SLA- 334 Content for the ADVERTISE event is shown in Figure 4. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |dir| Traffic Class count | Class Desc Len| | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 341 | | 342 ~ Traffic Class Description ~ 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Elements Count| | 346 +-+-+-+-+-+-+-+-+ ~ 347 | | 348 ~ Traffic Class Elements (TLVs) ~ 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Service Count| | 352 +-+-+-+-+-+-+-+-+ ~ 353 | Traffic Class Service TLVs | 354 ~ ~ 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 ~ Repeat from Traffic Class Description for next Traffic Class ~ 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | | 362 ~ Repeat from direction for SLA in the other direction ~ 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 4 - SLA-Content for event ADVERTISE 368 SLA-content contains set of Traffic Class Elements (Classifiers) and 369 Service TLVs for a list of Traffic Classes. This list of Traffic 370 Classes MUST be specified for one direction first and then optionally 371 followed by for the opposite direction. 373 dir (Direction): 2 bit field that indicates Direction of the SLA. 374 The following values are defined: 376 0x0 = reserved 378 0x1 = incoming, to source AS from destination AS 380 0x2 = outgoing, from source AS towards destination AS 382 0x3 = for future use 384 Traffic Class (Classifier Group) count: 16 bit field with the count 385 of number of classifier groups. The value of zero (0x00)in this 386 field is a special value which invalidates previous advertised SLA 387 (if any exist). 389 Class Descr Len: 8 bit field that contains the length of the Traffic 390 Class Description field. The value of zero in this field 391 indicates that no Traffic Class Description field follows. 393 Traffic Class Description: The description field MUST carry UTF-8 394 encoded description. 396 Elements (Classifier) Count: 8 bit field containing the count of 397 traffic elements. The value zero (0x00) means there are no 398 elements in the traffic class, and thus the traffic class is to 399 classify rest of the traffic not captured otherwise by other 400 traffic classes in the set for a given direction. 402 It is RECOMMENDED that Traffic Class that has 0 elements is 403 present last in the advertised list of Traffic Classes. 405 If an advertised message has it positioned somewhere else, then 406 the receiver MUST re-order it, for the forwarding purpose, to 407 the last position in the advertised list of Traffic Classes 408 from a given source AS. 410 The QoS attribute advertised from a specific source MUST NOT 411 have more than one such Traffic Classes (Traffic Class with 0 412 elements count). If there are more than one such Traffic 413 Classes present then it is an error condition which should 414 follow handling of such BGP message as described in the Error 415 handling section. 417 Classifier Element TLVs: (optional) variable length field containing 418 as many TLVs specified by the Elements count field. Each TLV has 419 the following format: 421 IPFIX Element Identifier: (8 bit type field) IPFIX Identifiers 422 listed in Table 1. 424 Size of Value field: (8 bit field) - Indicates the length of 425 the value field. 427 Value: A variable field containing a value appropriate for the 428 IPFIX element. It is an error if the IPFix field does not 429 contain the appropriate format (see BGP error handling in 430 section 6). Only the IPFIX elements shown in Table 1 are 431 supported. 433 Any Traffic Class element advertised in the QoS attribute only 434 applies to the NLRI advertised (AFI/SAFIs) within the BGP UPDATE 435 message the QoS attribute is contained in. If a receiver receives 436 a BGP UPDATE message with QoS/SLA attribute for an NLRI that it 437 does not support then the receiver MUST NOT install that 438 advertised SLA and continue to forward this attribute as an 439 optional transitive attribute. 441 Service Count: 8 bit count of Traffic Class Service TLVs following 442 this count. A value of zero is a special value indicating "no 443 bounded service" (a.k.a., Best Effort (BE)). 445 Traffic Class Service TLVs: (optional) variable length field with 446 the following format for the TLVs 448 Traffic Class Service type: 16-bit field which specifies a 449 service type. Each service type is detailed in Section 3.3.2. 450 The list of available service types are, 452 0x00 = reserved 454 0x01 = TRAFFIC_CLASS_TSPEC 456 0x02 = L2_OVERHEAD 458 0x03 = MINRATE_IN_PROFILE_MARKING 460 0x04 = MINRATE_OUT_PROFILE_MARKING 462 0x05 = MAXRATE_IN_PROFILE_MARKING 464 0x06 = MAXRATE_OUT_PROFILE_MARKING 466 0x07 = DROP_THRESHOLD 468 0x08 = RELATIVE_PRIORITY 470 0x09 = SUB_TRAFFIC_CLASSES 472 Length of value field: 08-bit field that specifies the size of 473 a value field to follow. 475 TRAFFIC_CLASS_TSPEC type has a fixed size length of a value. 476 It is 96 bits specifying Tspec described in Section 3.3.2.1. 478 L2_OVERHEAD type has a fixed size length of a value. It is 479 8 bits as described in Section 3.3.2.2. 481 MINRATE_IN_PROFILE_MARKING type has a variable length value 482 (see Section 3.3.2.3). 484 MINRATE_OUT_PROFILE_MARKING type has a variable length value 485 (see Section 3.3.2.4). 487 MAXRATE_IN_PROFILE_MARKING type has a variable length value 488 (see Section 3.3.2.5). 490 MAXRATE_OUT_PROFILE_MARKING type has a variable length value 491 (see Section 3.3.2.6). 493 DROP_THRESHOLD type has a variable length value (see 494 Section 3.3.2.8). 496 RELATIVE_PRIORITY has a fixed size length of 4 bits 497 specifying the priority value. (see Section 3.3.2.9). 499 0x09 = SUB_TRAFFIC_CLASSES is a variable length field which 500 allows sub-classes to be specified under traffic classes 501 (see Section 3.3.2.10). 503 Value field: field containing value appropriate for one of the 504 Service Types. It is an error if this field does not contain 505 the appropriate format (see BGP error handling section for 506 details). 508 3.3.1. Supported IPFIX values for Classifier Elements 510 IPFIX [RFC7012] has well defined identifier set for a large number of 511 packet attributes; an IPFIX IANA registry maintains values for packet 512 classifier attributes (https://www.ietf.org/assignments/ipfix"). 513 Only the IPFIX attributes listed in Table 1 are supported by BGP SLA 514 exchange. Any new attribute to be supported by SLA QOS MUST be added 515 by a Standards Action. 517 +----+----------------------------+ 518 | ID | Name | 519 +----+----------------------------+ 520 |195 | ipDiffServCodePoint | 521 |203 | mplsTopLabelExp | 522 |244 | dot1qPriority | 523 | 8 | sourceIPv4Address | 524 | 27 | sourceIPv6Address | 525 | 9 | sourceIPv4PrefixLength | 526 | 29 | sourceIPv6PrefixLength | 527 | 44 | sourceIPv4Prefix | 528 |170 | sourceIPv6Prefix | 529 | 12 | destinationIPv4Address | 530 | 28 | destinationIPv6Address | 531 | 13 | destinationIPv4PrefixLength| 532 | 30 | destinationIPv6PrefixLength| 533 | 45 | destinationIPv4Prefix | 534 |169 | destinationIPv6Prefix | 535 | 4 | protocolIdentifier | 536 | 7 | sourceTransportPort | 537 | 11 | destinationTransportPort | 538 +----+----------------------------+ 540 Table 1 542 3.3.2. Traffic Class Service TLVs 544 3.3.2.1. Traffic Class TSPEC TLV 546 The TRAFFIC_CLASS_TSPEC TLV consists of: 548 type = 0x01 550 length = 96 bits (12 octets) TSpec field 552 value = 96 bits, TRAFFIC_CLASS_TSPEC value consists of the (r), 553 (b), (p) parameters as described in Invocation Information section 554 of [RFC2212] and shown in Figure 5. Note that inheriting the 555 definition of TSpec here does not enable RFC2212 functionality. 556 Only the values of the Traffic Specification are used in this 557 specification. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Minimum Rate (r) (32-bit IEEE floating point number) | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Burst Size (b) (32-bit IEEE floating point number) | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Maximum Rate (p) (32-bit IEEE floating point number) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 5 - Traffic Class TSPEC 571 Format of Parameters (r), (b) and (p): are 32-bit IEEE floating 572 point numbers. Positive infinity is represented as an IEEE single 573 precision floating-point number with an exponent of all ones and a 574 sign mantissa of all zeros. The format of IEEE floating-point 575 numbers is further summarized in [RFC4506]. 577 Parameter (r): indicates min-rate of the traffic class. This rate 578 indicates the minimum rate, measured in octets of Layer 2 (L2) 579 datagrams per second, that the service advertiser is providing for 580 a given class of traffic on advertiser's hop. Note that it does 581 not necessarily translate to a minimum rate service to the 582 receiver of an SLA unless the traffic class definition clearly 583 represents a sole receiver of an SLA. If there is no SLA for min- 584 rate, the value of (r) MUST be set to 0. 586 Parameter (b): indicates maximum burst size, measured in octets of 587 L2 datagram size. Since queuing delay can be considered a 588 function of burst size (b) and min-rate (r), in presence of non- 589 zero parameter (r), parameter (b) represents bounded delay for the 590 Traffic Class. This delay is a single hop queuing delay when SLA 591 is to be implemented at the resource constrained bottleneck. In 592 other words this burst size can be considered as a buffer size. 593 Value of 0 for parameter (b) means the advertiser does not mandate 594 specific bounded delay. 596 Parameter (p): indicates max-rate of the traffic class. Just like 597 min-rate, max-rate, measured in octets of L2 packets per second, 598 field here also indicates service provided by advertiser. If 599 advertiser does not have any specific value to set for a given 600 class of traffic, it MAY be set to physical interface line rate or 601 any other indirect limit that may affect this class' maximum rate. 602 In absence of any such known value, it MUST be set to positive 603 infinity. Value 0 is considered an error. 605 3.3.2.2. Traffic Class L2 Overhead 607 The L2_OVERHEAD traffic class consists of: 609 Type = 0x02 (L2_OVERHEAD) 611 Length = 1 octet 613 value = 8 bits, count of L2 overhead from sender in bytes 615 By default the packet rate and other packet size related parameters 616 advertised in an SLA include the L2 packet overhead. For the 617 receiver (of the SLA at next hop),this overhead is the L2 overhead of 618 the local link where advertised SLA is received. 620 However, in cases where advertised SLA is for a receiver multiple 621 hops away, L2 overhead from the source perspective may be different 622 from the local L2 overhead at the receiver. In such cases, the 623 explicit notification of size of L2 overhead from a sender is 624 necessary for the a receiver to be able to know the L2 overhead 625 required by the sender. When the receiver chooses to react to an 626 advertised SLA and if the L2 Overhead service type is present in 627 advertised SLA, the receiver MUST use the explicit advertised L2 628 overhead rather than the local L2 overhead. 630 If SLA is required to consider only IP packet size, the sender MAY 631 advertise this service with a value of 0. 633 3.3.2.3. Traffic Class for MINRATE_IN_PROFILE_MARKING 635 The MINRATE_IN_PROFILE_MARKING traffic class consists of: 637 Type = 0x03 = MINRATE_IN_PROFILE_MARKING 639 Length = 2 octets 641 Value: 643 Marking code-point type = 8 bits (1 octet) IPFIX Element 644 Identifier. 646 Marking code-point value = 8 bits (1 octet) code-point number. 648 The marking code-point type of 0x00 is a drop identifier; the length 649 in this case is zero. 651 The following table lists the supported IPFIX Identifiers: 653 +----+----------------------------+ 654 | ID | Name | 655 +----+----------------------------+ 656 |195 | ipDiffServCodePoint | 657 |203 | mplsTopLabelExp | 658 |244 | dot1qPriority | 659 +----+----------------------------+ 661 Table 2 663 3.3.2.4. Traffic Class for MINRATE_OUT_PROFILE_MARKING 665 The MINRATE_OUT_PROFILE_MARKING traffic class consists of: 667 Type = 0x04 = MINRATE_OUT_PROFILE_MARKING 669 Length = 2 octets 671 Value: 673 Marking code-point type = 8 bits (1 octet) IPFIX Element 674 Identifier. 676 Marking code-point value = 8 bits (1 octet) code-point number. 678 The marking code-point type of 0x00 is a drop identifier; the length 679 in this case is zero. 681 The following table lists the supported IPFIX Identifiers: 683 +----+----------------------------+ 684 | ID | Name | 685 +----+----------------------------+ 686 |195 | ipDiffServCodePoint | 687 |203 | mplsTopLabelExp | 688 |244 | dot1qPriority | 689 +----+----------------------------+ 691 Table 3 693 3.3.2.5. Traffic Class for MAXRATE_IN_PROFILE_MARKING 695 The MAXRATE_IN_PROFILE_MARKING traffic class consists of: 697 Type = 0x05 = MAXRATE_IN_PROFILE_MARKING 699 Length = 2 octets 700 Value: 702 Marking code-point type = 8 bits (1 octet) IPFIX Element 703 Identifier. 705 Marking code-point value = 8 bits (1 octet) code-point number. 707 The marking code-point type of 0x00 is a drop identifier; the length 708 in this case is zero. 710 The following table lists the supported IPFIX Identifiers: 712 +----+----------------------------+ 713 | ID | Name | 714 +----+----------------------------+ 715 |195 | ipDiffServCodePoint | 716 |203 | mplsTopLabelExp | 717 |244 | dot1qPriority | 718 +----+----------------------------+ 720 Table 4 722 3.3.2.6. Traffic Class for MAXRATE_OUT_PROFILE_MARKING 724 The MAXRATE_OUT_PROFILE_MARKING traffic class consists of: 726 Type = 0x06 = MAXRATE_OUT_PROFILE_MARKING 728 Length = 2 octets 730 Value: 732 Marking code-point type = 8 bits (1 octet) IPFIX Element 733 Identifier. 735 Marking code-point value = 8 bits (1 octet) code-point number. 737 The marking code-point type of 0x00 is a drop identifier; the length 738 in this case is zero. 740 The following table lists the supported IPFIX Identifiers: 742 +----+----------------------------+ 743 | ID | Name | 744 +----+----------------------------+ 745 |195 | ipDiffServCodePoint | 746 |203 | mplsTopLabelExp | 747 |244 | dot1qPriority | 748 +----+----------------------------+ 750 Table 5 752 3.3.2.7. Precedence between MINRATE and MAXRATE 754 The precedence between MINRATE_IN_PROFILE_MARKING, 755 MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING, and 756 MAXRATE_OUT_PROFILE_MARKING when all four are advertised is: 758 o MINRATE_IN_PROFILE_MARKING takes highest precedence (that is over 759 MAXRATE_IN_PROFILE_MARKING), 761 o MAXRATE_IN_PROFILE_MARKING takes precedence over 762 MINRATE_OUT_PROFILE_MARKING, and 764 o MAXRATE_OUT_PROFILE_MARKING takes precedence over 765 MINRATE_OUT_PROFILE_MARKING 767 3.3.2.8. Traffic Class for DROP_THRESHOLD 769 The DROP_THRESHOLD traffic class consists of: 771 Type = 0x07 - DROP_THRESHOLD 773 Length = 1 octet that specifies total length of all set of drop 774 thresholds. 776 A set of drop threshold contains list of code-points of a specific 777 type sharing a threshold in unit of bytes. There MAY be more than 778 one set of such threshold for this Service Type per Traffic Class. 780 Value: number of set of thresholds and values in form of a sub-TLV 781 for each set. 783 Number of set of thresholds = 1 octet 785 sub-TLV for each set: Each sub-TLV specifies a code-point type/ 786 values that the burst size is applicable to. The sub-TLV is in 787 the form of a (code-point type, value length, value) where 788 value = list of code-points + burst size in unit of bytes 789 applicable to that code-points. 791 sub-TLV code point type = 8 bits (1 octet) IPFIX Element 792 Identifier from the list shown in Table 6. 794 sub-TLV Length = 1 octet that specifies total length for set 795 of code-points and burst size. 797 sub-TLV Value: variable length field with 799 sequence of code points - one code-point value specified 800 in 1 octet. 802 4 octets burst size - 32 bit (4 octets) IEEE Floating 803 point number. 805 +----+----------------------------+ 806 | ID | Name | 807 +----+----------------------------+ 808 |195 | ipDiffServCodePoint | 809 |203 | mplsTopLabelExp | 810 |244 | dot1qPriority | 811 +----+----------------------------+ 813 Table 6 815 3.3.2.9. Traffic Class for Relative Priority 817 The RELATIVE_PRIORITY traffic class consists of: 819 Type = 0x08 - RELATIVE_PRIORITY 821 Length = 4 bits 823 Value: 825 A value from range of 0 - 15. Lower the value means higher the 826 priority. 828 Relative priority indicates scheduling priority of this traffic 829 class. Voice traffic, for example, which requires lowest latency 830 compared to any other traffic, may have lowest value advertised in 831 relative priority. For two different traffic classification groups 832 where one application group may be considered more important than the 833 other but from a scheduling perspective does not require to be 834 distinguished with a different priority, relative priority for those 835 classification groups may be advertised with the same value. 837 3.3.2.10. Traffic Class for Sub-Traffic Classes 839 The SUB_TRAFFIC_CLASSES traffic class consists of: 841 Type = 0x09 - SUB_TRAFFIC_CLASSSES 843 length = the combined length of a set of traffic Class TLVs 844 included in a Sub-Traffic Classes grouping 846 value = sequence of traffic class TLVs 848 For SLAs where a specific Traffic Class may further have different 849 sub-services for a sub-group of Classifier Elements, this service 850 type SHOULD be used to further divide Traffic Class in multiple sub- 851 classes. Each sub-class is then defined with their own classifier 852 elements and service types. 854 4. Originating SLA Notification 856 The QoS attribute MUST only be added by the originator and MUST NOT 857 be added during BGP propagation. 859 BGP UPDATE message with the QoS Attribute carrying SLA parameters 860 SHOULD NOT be sent periodically just for the purpose of KEEPALIVE 861 between two points. Some sort of SLA policy change may be considered 862 as a trigger for the advertisement. 864 For any modified SLA parameters, the originator MUST re-advertise the 865 entire set of SLA parameters. There is no provision to advertise 866 partial set of parameters. To invalidate previously advertised SLA 867 parameters, a message MUST be sent with the same SLA id for the same 868 source with the Traffic Class count set to 0. 870 4.1. SLA Contexts 872 In certain cases, the advertisement of a QoS Attribute in a BGP 873 UPDATE message may relate to an SLA for aggregate traffic over a 874 point-to-point connection between a specific destination and a 875 specific source. A point-to-point connection may be the physical 876 link, that connects two BGP peers, or may be a virtual link (e.g. a 877 tunnel). In such cases, a BGP update message with source AS number 878 and NLRI prefix of source end-point can uniquely identify physical/ 879 virtual link in order to establish the context for the advertised 880 SLA's for that point to point link. 882 In the simplest case where provider (e.g., PE) and Customer (e.g., 883 CE) devices are directly connected via a physical link and have only 884 a single link between them, the CE can uniquely identify the 885 forwarding link to PE with the following: 887 o AS number of the PE, 889 o NLRI prefix being an IP address of PE, 891 o next hop to CE (that is the next hop address from CE to PE). 893 The SLA advertised in the QoS attribute in the BGP UPDATE message 894 sent from the PE to a CE, along with the PE's AS number and IP 895 address, establishes SLA context for the aggregate traffic through 896 CE-to-PE link. 898 The SLA advertised in the QoS attribute in the BGP UPDATE message 899 from PE to CE, with PE's AS number and any other prefix establishes 900 SLA for that specific prefix's traffic as a subset of traffic under 901 CE-to-PE link. 903 Even though this example is in the context of IP prefixes, QoS 904 attribute's SLA exchange does not have to be limited to the IP 905 address family (IPv4 and IPv6). SLA advertisement is generic to all 906 forms of NLRI types that are supported by the BGP specification (like 907 IPv4, IPv6, VPN-IPv4, VPN-IPv6). 909 4.1.1. SLA Advertisement for Point-to-Point Connection 911 When BGP UPDATE message with the QoS Attribute with SLA is used to 912 advertise the QoS SLA for a point-to-point connection (physical or 913 logical), the next hop in the BGP message is used with the prefix of 914 the source end-point of the point to point connection. 916 The destination AS number in the QoS SLA attribute is typically set 917 to the AS of the BGP peer's IP-Address. 919 If the source AS number in the QoS SLA Attribute is set to zero, the 920 source AS and Destination AS fields in the QoS SLA attribute are 921 ignored. This occurs if the BGP peer is sending an UPDATE message 922 with the QOS SLA directly to a BGP peer (next-hop BGP peer). 924 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away 926 When a BGP UPDATE message with a QoS SLA attribute is to be sent by a 927 BGP peer beyond next hop peer, the value of source AS in the QoS 928 attribute MUST be set by the originator of the UPDATE message. If 929 such an update is meant to be for a specific list of AS(es) as 930 receivers, then the list of destination AS(es) MUST be explicitly 931 described in the QoS attribute message to avoid flooding of the QoS 932 attribute data in the network beyond those destinations. 934 If a new prefix is added in an AS for which SLA parameters have 935 already been advertised before for other existing prefixes, and if 936 traffic to this new prefix is subject to the same SLA advertised 937 earlier, then the BGP UPDATE for this new prefix may include QoS 938 attribute containing just an SLA id for an SLA id that was advertised 939 earlier. This BGP UPDATE message does not require to have the whole 940 SLA content. The SLA id is sufficient to relate SLA parameters to 941 new advertised prefixes. 943 5. SLA Attribute Handling at Forwarding Nodes 945 The propagation of the QoS Attribute in the BGP UPDATE depends on the 946 rules detailed in the following sub-sections for forwarding the QoS 947 Attribute. 949 5.1. BGP Node Capable of Processing QoS Attribute 951 If a BGP peer is capable of processing a QoS attribute in a BGP 952 UPDATE message, it MAY process the QoS attribute. If UPDATE has a 953 QoS Attribute with a list of destination ASes, it MAY trim the list 954 and adjust the count of the destination AS to exclude ones that are 955 not required in further announcement of BGP UPDATE messages. 957 BGP peer MUST drop SLA related sub-type from the QoS attribute, if 958 there are no more ASes from the QoS Attribute's destination list in 959 the forwarding path. The rest of the QoS attribute contents MAY be 960 forwarded if there exist other sub-types of QoS attribute and 961 forwarding rules meets other sub-types requirements. If there is no 962 other sub-types in the QoS attribute content then the node MUST drop 963 the entire QoS attribute all together. The other attributes and NLRI 964 information MAY be announced further if they meet rules defined by 965 other attributes and BGP specification. 967 Except extracting the entire SLA sub-type of the QoS attribute and 968 trimming the list of destination AS list, all other content MUST NOT 969 be modified by any intermediate receivers of the message. 971 5.2. SLA Attribute Handling at Receiver 973 Reception of and processing of advertised QoS SLA content are 974 optional for the receiver. While reacting to SLA advertisement in a 975 QoS attribute, 977 o the receiving BGP peer SHOULD invalidate previous advertised SLA 978 parameters if one exists for the same SLA id and source AS. If 979 the new advertised SLA has a non-zero traffic count, then the new 980 advertised SLA SHOULD be installed. If new advertised SLA update 981 is with Traffic Class count 0, then no further action is required. 983 o When BGP UPDATE messages are triggered only as a result of SLA 984 policy change, BGP UPDATE message forwarding beyond intended BGP 985 peer receivers is not necessary. If the receiver device 986 implementation supports policy based filtering, then the receiver 987 MAY implement a policy to filter such messages based on the prefix 988 and attribute. 990 If QoS attribute with the SLA is advertised to the next hop BGP peer 991 who is a neighbor, the receiver MAY implement advertised SLA for the 992 whole link; the link could be a physical or virtual connected to the 993 neighbor. If the QoS Attribute with the SLA is advertised to a BGP 994 peer which is not the next hop neighbor, then receiver may establish 995 advertised SLA for that specific prefix list under the relevant link. 996 It is completely up to the receiver to decide for which prefixes it 997 should accept advertised SLA and for which ones it will not accept. 999 6. Error Handling 1001 Error conditions, while processing of the QoS attribute, MUST be 1002 handled with the approach of attribute-discard as described in 1003 [RFC7606]. In such condition, the receiver SHOULD also cleanup any 1004 previously installed SLA state for the same prefix. 1006 7. Traffic Class Mapping 1008 It is possible that forwarding methods used in two different ASes 1009 could be different. For example, provider may tunnel a customer's IP 1010 traffic thru an MPLS infrastructure. In such cases, the traffic 1011 class definition for QoS services may differ between the ASes. For 1012 the meaningful use of advertised SLA in such cases, the receiver is 1013 required to map the remote traffic class to the local traffic class. 1015 In the example given, traffic classification in Customer AS could be 1016 IP Diffserv-based whereas traffic classification in Provider AS could 1017 be MPLS TC-based. Thus for advertised MPLS TC-based SLA would 1018 require to map traffic class from IP Diffserv-based to MPLS TC type 1019 [RFC3270]. 1021 There are well-defined recommendations that exist for traffic class 1022 mapping between two technologies (e.g. [RFC3270] maps between DSCP 1023 and MPLS TC). Receiver MAY use those defined recommendations for 1024 traffic class mapping or MAY define its own as per its network 1025 Traffic Class service definition to map to advertised Traffic 1026 Classes. It is completely up to the receiver how to define such 1027 traffic class mapping. 1029 8. Deployment Considerations 1031 One of the use cases is for a provider to advertise contracted SLA 1032 parameters to a Customer Edge (CE) in cases where eBGP is deployed 1033 between PE and CE. The SLA parameters may already be provisioned by 1034 the provider on the PE device (facing CE). This provisioned SLA 1035 parameters are then advertised thru proposed BGP QoS attribute to the 1036 CE device. The CE device may read the attribute and SLA sub-type 1037 content to implement the QoS policy on the device. 1039 Contracted SLA from PE to CE may be full line-rate or sub line-rate 1040 or finer granular controlled services. The advertised SLA can be 1041 useful when contracted service is sub-rate of a link and/or when for 1042 finer granular traffic classes that are controlled (e.g. voice, video 1043 services may be capped to certain rate). 1045 _______________ 1046 __________ / \ 1047 / \ / \ 1048 / \ / \ 1049 |CustomerSite|-----| Provider | 1050 \ C/E P\E / 1051 \__________/ \ / 1052 \_______________/ 1053 AS 3 AS 2 1055 SLA_ADVERTISE: AS2 to AS3 1056 NLRI = PE ip address 1058 Figure 6 - Example 1 1060 Another use case can be to advertise SLAs among different network 1061 sites within one Enterprise network. In Hub and Spoke deployments, 1062 Administrator may define SLAs at spoke and advertise QoS SLA 1063 parameters to the Hub thru BGP updates. In Figure 7, each spoke (AS1 1064 and AS2) are connected to Hub (AS3) via a VPN tunnel. As shown in 1065 Figure 7, AS2 can advertise SLA to AS3 in the context of that tunnel 1066 ip address. 1068 AS 2 1069 _______________ ________ 1070 / \ / \ 1071 _____ / \-----| Spoke2 | 1072 / \ / \ \________/ 1073 | Hub |-----| Provider | ________ 1074 \______/ \ / / \ 1075 \ /-----| Spoke1 | 1076 AS 3 \_______________/ \________/ 1077 AS 1 1079 SLA_ADVERTISE: AS2 to AS3 1080 NLRI = AS2 tunnel address 1082 SLA_ADVERTISE: AS1 to AS3 1083 NLRI = AS1 tunnel address 1085 Figure 7 - Example 2 1087 Deployment options are not limited to involving CEs, PE-to-CE or CE- 1088 to-CE, only. For any contract between two providers, SLA parameters 1089 may be advertised from one to the other. 1091 9. Acknowledgements 1093 Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for 1094 their suggestions and to Christian Jacquenet, Ken Briley, Rahul 1095 Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier, 1096 Bruno Decraene for the review. 1098 10. IANA Considerations 1100 This document defines a new BGP optional transitive path attribute, 1101 called QoS Attribute. IANA action is required to allocate a new 1102 code-point in the BGP path Attributes registry. 1104 IANA is requested to create a registry for QoS Attribute subTypes. 1105 This is a registry of 1 octet value, to be assigned on a standards 1106 action/early allocation basis. The initial assignments are: 1108 QoS Attribute subTypes 1109 ============= ======== 1110 Reserved 0x00 1111 SLA 0x01 1112 Reserved 0x02-0xff (Standards Action) 1114 IANA is requested to create a registry for SLA Event Types. This is 1115 a registry of 4-bits value, to be assigned on a standards action or 1116 early allocation basis. The initial assignments are: 1118 QoS Attribute SLA Event Types 1119 ============= =============== 1120 Reserved 0x00 1121 ADVERTISE 0x01 1123 IANA is requested to create a registry to define QoS SLA Direction. 1124 This is the direction in forwarding path, advertised QoS SLA is 1125 applicable to. The values for QoS SLA direction are: 1127 QoS SLA Direction Value 1128 ================= ===== 1129 Reserved 0x00 1130 To source AS from destination AS 0x01 1131 From source AS to destination AS 0x02 1133 QoS SLA Traffic Class Element Types will be referring to existing 1134 IPFIX IANA types as listed in Table 1. 1136 IANA is requested to create a registry for QoS SLA Traffic Class 1137 Service Types. This is a registry of 2 octet values, to be assigned 1138 on a standards action/early allocation basis. The initial 1139 assignments are: 1141 Traffic Class Service Type Value 1142 ============================ ====== 1143 Reserved 0x00 1144 TRAFFIC_CLASS_TSPEC 0x01 1145 L2_OVERHEAD 0x02 1146 MINRATE_IN_PROFILE_MARKING 0x03 1147 MINRATE_OUT_PROFILE_MARKING 0x04 1148 MAXRATE_IN_PROFILE_MARKING 0x05 1149 MAXRATE_OUT_PROFILE_MARKING 0x06 1150 DROP_THRESHOLD 0x07 1151 RELATIVE_PRIORITY 0x08 1152 SUB_TRAFFIC_CLASSES 0x09 1154 11. Security Considerations 1156 The QOS attribute defined in this document SHOULD be used by the 1157 managed networks for enforcing Quality of Service policies and so 1158 there should not be any risks for identity thefts. To strengthen the 1159 security for the QoS attribute, RPKI based origin validation 1160 [RFC7115] MAY be used. In addition to the RPKI based origin 1161 validation, BGP Path Validation (e.g., [I-D.ietf-sidr-bgpsec- 1162 protocol]) procedures could be used over BGP QoS attribute and its 1163 associated prefix in producing the digital signature that can be 1164 carried within the signature SLA for the messages. This would help 1165 prevent any man- in-the-middle attacks. 1167 12. References 1169 12.1. Normative References 1171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1172 Requirement Levels", BCP 14, RFC 2119, 1173 DOI 10.17487/RFC2119, March 1997, 1174 . 1176 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1177 of Guaranteed Quality of Service", RFC 2212, 1178 DOI 10.17487/RFC2212, September 1997, 1179 . 1181 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1182 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1183 Protocol Label Switching (MPLS) Support of Differentiated 1184 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 1185 . 1187 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1188 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1189 DOI 10.17487/RFC4271, January 2006, 1190 . 1192 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 1193 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 1194 2006, . 1196 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1197 for IP Flow Information Export (IPFIX)", RFC 7012, 1198 DOI 10.17487/RFC7012, September 2013, 1199 . 1201 [RFC7115] Bush, R., "Origin Validation Operation Based on the 1202 Resource Public Key Infrastructure (RPKI)", BCP 185, 1203 RFC 7115, DOI 10.17487/RFC7115, January 2014, 1204 . 1206 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1207 Patel, "Revised Error Handling for BGP UPDATE Messages", 1208 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1209 . 1211 12.2. Informative References 1213 [I-D.ietf-netconf-restconf] 1214 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1215 Protocol", draft-ietf-netconf-restconf-09 (work in 1216 progress), December 2015. 1218 [I-D.ietf-sidr-bgpsec-protocol] 1219 Lepinski, M., "BGPsec Protocol Specification", draft-ietf- 1220 sidr-bgpsec-protocol-14 (work in progress), December 2015. 1222 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1223 and W. Weiss, "An Architecture for Differentiated 1224 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1225 . 1227 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1228 and D. McPherson, "Dissemination of Flow Specification 1229 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1230 . 1232 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1233 the Network Configuration Protocol (NETCONF)", RFC 6020, 1234 DOI 10.17487/RFC6020, October 2010, 1235 . 1237 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1238 and A. Bierman, Ed., "Network Configuration Protocol 1239 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1240 . 1242 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1243 Connectivity Provisioning Profile (CPP)", RFC 7297, 1244 DOI 10.17487/RFC7297, July 2014, 1245 . 1247 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1248 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1249 October 2015, . 1251 Authors' Addresses 1253 Shitanshu Shah 1254 Cisco Systems 1255 170 W. Tasman Drive 1256 San Jose, CA 95134 1257 US 1259 Email: svshah@cisco.com 1261 Keyur Patel 1262 Cisco Systems 1263 170 W. Tasman Drive 1264 San Jose, CA 95134 1265 US 1267 Email: keyupate@cisco.com 1269 Sandeep Bajaj 1270 Juniper Network 1271 1194 N. Mathilda Avenue 1272 Sunnyvale, CA 94089 1273 US 1275 Email: sbajaj@juniper.net 1277 Luis Tomotaki 1278 Verizon 1279 400 International 1280 Richardson, TX 75081 1281 US 1283 Email: luis.tomotaki@verizon.com 1284 Mohamed Boucadair 1285 Orange 1286 Rennes 1287 35000 1288 France 1290 Email: mohamed.boucadair@orange.com