idnits 2.17.1 draft-hares-idr-flowspec-v2-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 : ---------------------------------------------------------------------------- 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 date (June 25, 2016) is 2862 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: 'RFC4271' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC4761' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-ephemeral-state' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-acl-model' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC6074' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC6483' is defined on line 612, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-03 == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-02 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-17 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7674 (Obsoleted by RFC 8955) == Outdated reference: A later version (-23) exists of draft-ietf-i2rs-ephemeral-state-10 == Outdated reference: A later version (-01) exists of draft-ietf-i2rs-fb-rib-data-model-00 == Outdated reference: A later version (-03) exists of draft-ietf-i2rs-pkt-eca-data-model-00 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-13 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-07 Summary: 4 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group S. Hares 3 Internet-Draft Huawei 4 Intended status: Standards Track June 25, 2016 5 Expires: December 27, 2016 7 BGP Flow Specification Version 2 8 draft-hares-idr-flowspec-v2-00.txt 10 Abstract 12 BGP flow specification version 1 (RFC5575) describes the distribution 13 of traffic filter policy (traffic filters and actions) which are 14 distributed via BGP to BGP peers. Three applications utilize this 15 traffic filter policy: (1) mitigation of Denial of Service (DoS), (2) 16 enabling of traffic filtering in BGP/MPLS VPNS, and (3)centralized 17 traffic control for networks with SDN or NFV controllers. 18 Application of centralized traffic utilizing BGP Flow Specification 19 traffic filters may need user-ordered filters rather than RFC5575's 20 strict ordering of filters and defined ordering of actions. 22 This document proposes a new BGP Flow specification version 2 that 23 supports user-order of filters and actions plus allowing more actions 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 27, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. RFC5575 vs. NETCONF/RESTCONF/I2RS Flow Filters . . . . . 4 61 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 6 63 2.2. RFC 2119 language . . . . . . . . . . . . . . . . . . . . 6 64 3. Dissemination of BGP Flow Specification version 2 NLRI and 65 Wide Communities . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Encoding of BGP-FS v2 Filters . . . . . . . . . . . . . . 7 67 3.2. Encoding of BGP-FS v2 Actions . . . . . . . . . . . . . . 7 68 3.3. Required NLRI Validation . . . . . . . . . . . . . . . . 8 69 4. Optional Security Additions . . . . . . . . . . . . . . . . . 8 70 4.1. BGP FS v2 and BGPSEC . . . . . . . . . . . . . . . . . . 9 71 4.2. BGP FS v2 with with ROA . . . . . . . . . . . . . . . . . 9 72 4.3. Revise Flow Specification Security for centralized Server 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 7.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 BGP flow specification [RFC5575] describes the distribution of 83 filters and actions that apply when packets are received on a router 84 with the flow specification function turned on. If one considers the 85 reception of the packet as an event, then BGP flow specification 86 describes a set of minimalistic Event-MatchCondition-Action (ECA) 87 policies were the match-condition is defined in the BGP NLRI, and the 88 action is defined either by the default condition (accept traffic) or 89 actions defined in Extended BGP Communiites values [RFC4360]. 91 The initial set of policy [RFC5575] and [RFC7674] for this policy 92 includes 12 types of match filters encoded in two application 93 specific AFI/SAFIs for the IPv4 AFI. 95 IP traffic: AFI:1, SAFI, 133; 96 BGP/MPLS VPN AFI:1 VPN SAFI, 134) for IPv4. 98 The popularity of these flow specification filters in deployment for 99 DoS and SDN/NFV has led to the requirement for more BGP flow 100 specification match filters in the NLRI and more BGP flow 101 specification actions. 103 This document describes distribution of two new BGP Flow 104 Specification NLRI (2 AFI/SAFI pairs) that allow user-ordered list of 105 traffic match filters, and user-ordered traffic match actions encoded 106 in BGP Wide Communities. 108 o section 2 - Definitions, 110 o section 3 - Rules for dissemination of Flow Specification v2, 112 o section 4 - Optional Security, 114 o section 5 - IANA considerations, 116 o section 6 - security considerations. 118 The rest of this section provides background on BGP Flow 119 Specification filters interaction with I2RS Filter-Based RIBs carried 120 by NETCONF/RESTCONF protocol. Figure 1 below is a logial description 121 of BGP Flow Specification rules that combine filters in BGP NLRI with 122 actions in BGP Extended communities. 124 +-----------------------------+ 125 | Flow Specification (FS) | 126 | Policy | 127 +-----------------------------+ 128 ^ ^ 129 | | 130 | | 131 +--------^-------+ +-------^-------+ 132 | FS Rule | | FS Rule | 133 +----------------+ +---------------+ 134 : : 135 : : 136 ......: :..... 137 : : 138 +---------V---------+ +----V-------------+ 139 | Rule Condition | | Rule Action | 140 | in BGP NLRIs | | in BGP extended | 141 | SAFI 133, 134 | | Communities | 142 +-------------------+ +------------------+ 143 : : : : : : 144 .....: . :..... .....: . :..... 145 : : : : : : 146 +----V---+ +---V----+ +--V---+ +-V------+ +--V-----++--V---+ 147 | Match | | match | |match | | Action | | action ||action| 148 |Operator| |Variable| |Value | |Operator| |variable|| Value| 149 |*1 | | | | | |(subtype| | || | 150 +--------+ +--------+ +------+ +--------+ +--------++------+ 152 *1 match operator may be complex. 154 Figure 1: BGP Flow Specification Policy 156 BGP Flow Specification (BGP-FS) ([RFC5575] and 157 [I-D.raszuk-idr-rfc5575bis]) describes how to distribute the BGP Flow 158 Specification policy as BGP routes which are locally configured on 159 the originating BGP peer. Like BGP routes, if the BGP peer session 160 drops then BGP Flow Specification routes are dropped. [RFC5575] and 161 [I-D.raszuk-idr-rfc5575bis] do not indicate how the BGP Flow 162 Specification policy is installed in the kernel. 164 1.1. RFC5575 vs. NETCONF/RESTCONF/I2RS Flow Filters 166 [RFC5575] describes the dissemination of flow specification rules 167 policy is similar to the the statically configured Filter-Based RIB 168 described in [I-D.ietf-i2rs-fb-rib-data-model], and the I2RS Filter- 169 Based RIB ([I-D.ietf-i2rs-fb-rib-info-model], 170 [I-D.ietf-i2rs-fb-rib-data-model], 171 [I-D.ietf-i2rs-pkt-eca-data-model]). These FB-RIBs start on the 172 reception of a packet using match filters to match frames (L2) or 173 packet data (L3/L4/Application), and perform actions as shown in 174 figure 2. 176 +-----------+ +------------+ 177 |Rule Group | | Rule Group | 178 +-----------+ +------------+ 179 ^ ^ 180 | | 181 | | 182 +--------^-------+ +-------^-----------+ 183 | Rule | | Rule | 184 +----------------+ +-------------------+ 185 : : : : 186 :.................: : : : 187 : |.........: : : 188 +--V--+ +--V--+ : : 189 | name| |order| .........: :..... 190 +-----+ +-----+ : : 191 : : 192 +--------------V-------+ +--V------------+ 193 | Rule Match condition | | Rule Action | 194 +----------------------+ +---------------+ 195 : : : : : : 196 .....: . :..... .....: . :..... 197 : : : : : : 198 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 199 | Match | | match | |match | | Action || action ||action| 200 |Operator| |variable| |Value | |Operator||Variable|| Value| 201 +--------+ +--------+ +------+ +--------++--------++------+ 203 Figure 2: I2RS Filter-Based RIB Policy 205 [I-D.ietf-i2rs-fb-rib-data-model] suggests that the storage of BGP 206 Flow Specification routes in the kernel should utilize the same 207 format as the statically configured FB-RIB and the I2RS ephemeral FB- 208 RIB so that these traffic filters may be compared. This draft also 209 proposes that precedence between these three sources of filters in 210 the kernel (statically configured, I2RS ephemeral, and BGP ephemeral 211 routes) can either set by local policy or defaults. If it is set by 212 defaults [I-D.ietf-i2rs-fb-rib-data-model] suggests the default 213 precedence between static, I2RS, and BGP-FS installed filters is: 215 o static FB-RIB -highest precedence (wins all ties) 217 o I2RS FB-RIB - middle preference (wins over BGP-FS originated 218 routes, loses to static FB-RIB), 220 o BGP-FS installed Filters - lows preference (loses to static and 221 I2RS FB-RIB) 223 2. Definitions 225 2.1. Definitions and Acronyms 227 NETCONF: The Network Configuration Protocol [RFC6241]. 229 RESTconf - http programmatic protocol to access yang modules 230 [I-D.ietf-netconf-restconf] 232 BGPSEC - secure BGP [I-D.ietf-sidr-bgpsec-protocol]. 234 I2RS - Interface to Routing System [I-D.ietf-i2rs-architecture]. 236 BGP Session ephemeral state - state which does not survive the 237 loss of BGP peer, 239 Ephemeral state - state which does not survive the reboot of a 240 software module, or a hardware reboot. Ephemeral state can be 241 ephemeral configuration state or operational state. 243 configuration state - state which persist across a reboot of 244 software module within a routing systsem or a reboot of a hardware 245 routing device. 247 2.2. RFC 2119 language 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in [RFC2119]. 253 3. Dissemination of BGP Flow Specification version 2 NLRI and Wide 254 Communities 256 The BGP Flow Specification version 2 (BGP-FS v2) uses an NRLI with 257 the format for AFI/SAFI (SAFI = TBD) for IP flow, and AFI/SAFI for 258 BGP/MPLS (SAFI = TBD). This NLRI information is encoded using 259 MP_READ_NRI and MP_UNREACH_NLRI attributes defined in [RFC4760]. 260 Whenever the corresponding application does not require Next-HOP 261 information, this shall be encoded as zero-octet length Next Hop in 262 the MP_REAC_NLRI and ignored upon receipt. 264 Implementatinos wishing to exchange flow specificastion rules MUST 265 use BGP's Capability Advertisement facility to exchange the 266 Multiprotocol Extension Capability Code (Code 1) as defined in 267 [RFC4760]. 269 3.1. Encoding of BGP-FS v2 Filters 271 The AFI/SAFI NLRI for BGP Flow Specification has the format 273 +------------------------+ 274 |length (2 octets) | 275 +------------------------+ 276 | Sub-TLVs (variable) | 277 | +====================+ | 278 | | order (2 octets) | | 279 | +--------------------+ | 280 | | type (2 octets) | | 281 | +--------------------+ | 282 | | length (2 octets) | | 283 | +--------------------+ | 284 | | value (variable) | | 285 | |[multiples of | | 286 | | 2 octets] | | 287 | +====================+ | 288 +------------------------+ 290 Figure 16 - NRLI revision 292 where: 294 o length - is the length of the NLRI, 296 o Sub-TLVs contain a user-ordered set of filter components as 297 defined in [RFC5575] and [I-D.raszuk-idr-rfc5575bis]. The ranges 298 are defined as: standard BGP Flow Specification filters (types 299 0x01 - 0x3FFFF), and vendor specific filters (types 0x4ffff to 300 0x7FFFF) with type values 0x8000 to 0xFFFFFFFF reserved for future 301 use. Each sub-tlv has an length of 2 octets, and a variable 302 length value (in multiples of 2 octets). 304 Filters are process in the order specified by the user. If multiple 305 filters exist for the same order, the strict filter ordering defined 306 in [RFC5575] and [I-D.raszuk-idr-rfc5575bis] will be used for the 307 filters with the same value for user order. 309 3.2. Encoding of BGP-FS v2 Actions 311 The BGP-FS version 2 actions are passed in a Wide Community 312 [I-D.ietf-idr-wide-bgp-communities] atom with the following format. 314 +--------------------------+ 315 | order (2 octets) | 316 +--------------------------+ 317 | Action type (2 octets) | 318 +--------------------------+ 319 | Action length (2 octets) | 320 +--------------------------+ 321 | Action Values (variable) | 322 | (multiples of 2 octets) | 323 +--------------------------+ 325 Wide Community Atom 326 figure 17 328 where: 330 o Action type (2 octets) - is the type of action. These actions can 331 be standardized (0x0001 - 0x3ffff), vendor specific 332 (0x40000-0x7FFFF), or reserved (0x0, 0x80000-0xFFFFFFFF). 334 o Action length - length of actions including variable field, 336 o Action values - value of actions (variable) defined in individual 337 definitions. 339 The BGP Flow Specification (BGP-FS) atom can be part of the Wide 340 Community container (type 1) or the BGP Flow Specification Atom can 341 be part of the BGP Flow Specification container (type 2) which will 342 have: 344 +-----------------------------+ 345 | Source AS Number (4 octets)| 346 +-----------------------------+ 347 | list of atoms (variable) | 348 +-----------------------------+ 349 figure 18 351 3.3. Required NLRI Validation 353 Same as [RFC5575] and [I-D.raszuk-idr-rfc5575bis]. 355 4. Optional Security Additions 357 This section discusses the optional BGP Security additions for BGP-FS 358 v2: BGPSEC [I-D.ietf-sidr-bgpsec-protocol], ROA [RFC6482] and revised 359 security for flow specification distributed from a centralized server 360 within an AS [I-D.ietf-idr-bgp-flowspec-oid]. These optional 361 security parameters can be applied per BGP peer. 363 4.1. BGP FS v2 and BGPSEC 365 [RFC5575] does not require BGP Flow specifications to be passed 366 BGPSEC [I-D.ietf-sidr-bgpsec-protocol]. BGP FS v2 can be passed in 367 BGPSEC, but it is not required. 369 4.2. BGP FS v2 with with ROA 371 BGP-FS v2 can utilize ROAs in the validation. If BGP-FS v2 is used 372 with BGPSEC and ROA, the first thing is to vaildate the route within 373 BGPSEC and second to utilize BGP ROA to validate the route origin. 375 The BGP-FS peers using both ROA and BGP-FS validation determine that 376 a BGP Flow specification is valid if and only if one of the following 377 cases: 379 o If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in 380 destination address match filter and the following is true: 382 * A BGP ROA has been received to validate the originator, and 384 * the route is the best-match unicast route for the destination 385 prefix embedded in the match filter; or 387 o If a BGP ROA has not been received that matches the IPv4 or IPv6 388 destination address in the destination filter, the match filter 389 must abide by the [RFC5575] validation rules of: 391 * The originator match of the flow specification matches the 392 originator of the best-match unicast route for the destination 393 prefix filter embedded in the flow specification", and 395 * No more specific unicast routes exist when compared with the 396 flow destination prefix that have been received from a 397 different neighboring AS than the best-match unicast route, 398 which has been determined in step A. 400 The best match is defined to be the longest-match NLRI with the 401 highest preference. 403 4.3. Revise Flow Specification Security for centralized Server 405 The distribution of Flow Specifications from a centralized server 406 supports mitigation of DoS attacks. [I-D.ietf-idr-bgp-flowspec-oid] 407 suggests the following redefined procedure for validation for this 408 case: 410 A route is valid if the following conditions holds true: 412 o The originator of the flow specification matches the originator of 413 the best-match unicast route for the destination prefix embedded 414 in the flow specification. 416 o The AS_PATH and AS4_PATH attribute of the flow specification are 417 empty (on originating AS) 419 o The AS_PATH and AS4_PATH attribute of the flow specification does 420 not contain AS_SET and AS_SEQUENCE segments (on originating AS 421 with AS Confederation) 423 This reduced validation mechanism can be used for BGP-FS v2 within a 424 single domain. 426 5. IANA Considerations 428 This section complies with [RFC7153] 430 This document requests: 432 SAFI be defined for IPv4 (AFI = 1), IPv6 (AFI=2), L2VPN (AFI=25) 433 for BGP-FS 435 SAFI be defined for BGP/MPLS IPv4 (AFI = 1), IPv6 (AFI=2), L2VPN 436 (AFI=25) for BGP-FS 438 Registry be created for BGP-FS V2 filter component types with the 439 following ranges: 441 0x00 - reserved 443 0x01 - 0x3FFFF - standards action 445 0x40000- 0x7FFFF - vendor specific filters 447 0x80000 -0xFFFFFFFF - reserved 449 0x80000 -0xFFFFFFFF - reserved 451 Registry be created for BGP-FS v2 action types with the following 452 ranges: 454 0x0 - reserved 456 0x01 - 0x3ffff - standards action 458 0x40000 - 0x7ffff - vendor actions 459 0x80000 - 0xFFFFFFF - reserved 461 6. Security Considerations 463 The use of ROA improves on [RFC5575] to check the route orgination is 464 valid can improve the validation sequence for a multiple-AS 465 environment. The use of BGPSEC [I-D.ietf-sidr-bgpsec-protocol] to 466 secure the packet can increase security of BGP flow specification 467 information sent in the packet. 469 The use of the reduced validation within an AS 470 [I-D.ietf-idr-bgp-flowspec-oid] can provide adequate validation for 471 distribution of flow specification within an single autonomous system 472 for prevention of DDOS. 474 Distribution of flow filters may provide insight into traffic being 475 sent within an AS, but this information should be composite 476 information that does not reveal the traffic patterns of individuals. 478 7. References 480 7.1. Normative References 482 [I-D.ietf-idr-bgp-flowspec-oid] 483 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 484 Mohapatra, "Revised Validation Procedure for BGP Flow 485 Specifications", draft-ietf-idr-bgp-flowspec-oid-03 (work 486 in progress), March 2016. 488 [I-D.ietf-idr-wide-bgp-communities] 489 Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B., 490 Jakma, P., and R. Steenbergen, "Wide BGP Communities 491 Attribute", draft-ietf-idr-wide-bgp-communities-02 (work 492 in progress), May 2016. 494 [I-D.ietf-sidr-bgpsec-protocol] 495 Lepinski, M. and K. Sriram, "BGPsec Protocol 496 Specification", draft-ietf-sidr-bgpsec-protocol-17 (work 497 in progress), June 2016. 499 [I-D.raszuk-idr-rfc5575bis] 500 Raszuk, R., McPherson, D., Mauch, J., Greene, B., and S. 501 Hares, "Dissemination of Flow Specification Rules", draft- 502 raszuk-idr-rfc5575bis-00 (work in progress), June 2016. 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, 506 DOI 10.17487/RFC2119, March 1997, 507 . 509 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 510 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 511 DOI 10.17487/RFC4271, January 2006, 512 . 514 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 515 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 516 February 2006, . 518 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 519 "Multiprotocol Extensions for BGP-4", RFC 4760, 520 DOI 10.17487/RFC4760, January 2007, 521 . 523 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 524 LAN Service (VPLS) Using BGP for Auto-Discovery and 525 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 526 . 528 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 529 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 530 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 531 . 533 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 534 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 535 DOI 10.17487/RFC5226, May 2008, 536 . 538 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 539 and D. McPherson, "Dissemination of Flow Specification 540 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 541 . 543 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 544 and A. Bierman, Ed., "Network Configuration Protocol 545 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 546 . 548 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 549 Origin Authorizations (ROAs)", RFC 6482, 550 DOI 10.17487/RFC6482, February 2012, 551 . 553 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 554 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 555 March 2014, . 557 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 558 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 559 . 561 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 562 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 563 October 2015, . 565 7.2. Informative References 567 [I-D.ietf-i2rs-architecture] 568 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 569 Nadeau, "An Architecture for the Interface to the Routing 570 System", draft-ietf-i2rs-architecture-15 (work in 571 progress), April 2016. 573 [I-D.ietf-i2rs-ephemeral-state] 574 Haas, J. and S. Hares, "I2RS Ephemeral State 575 Requirements", draft-ietf-i2rs-ephemeral-state-10 (work in 576 progress), June 2016. 578 [I-D.ietf-i2rs-fb-rib-data-model] 579 Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, 580 D., and R. White, "Filter-Based RIB Data Model", draft- 581 ietf-i2rs-fb-rib-data-model-00 (work in progress), June 582 2016. 584 [I-D.ietf-i2rs-fb-rib-info-model] 585 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 586 R., Bogdanovic, D., and R. White, "Filter-Based RIB 587 Information Model", draft-ietf-i2rs-fb-rib-info-model-00 588 (work in progress), June 2016. 590 [I-D.ietf-i2rs-pkt-eca-data-model] 591 Hares, S., Wu, Q., and R. White, "Filter-Based Packet 592 Forwarding ECA Policy", draft-ietf-i2rs-pkt-eca-data- 593 model-00 (work in progress), June 2016. 595 [I-D.ietf-netconf-restconf] 596 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 597 Protocol", draft-ietf-netconf-restconf-13 (work in 598 progress), April 2016. 600 [I-D.ietf-netmod-acl-model] 601 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 602 "Network Access Control List (ACL) YANG Data Model", 603 draft-ietf-netmod-acl-model-07 (work in progress), March 604 2016. 606 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 607 "Provisioning, Auto-Discovery, and Signaling in Layer 2 608 Virtual Private Networks (L2VPNs)", RFC 6074, 609 DOI 10.17487/RFC6074, January 2011, 610 . 612 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 613 Origination Using the Resource Certificate Public Key 614 Infrastructure (PKI) and Route Origin Authorizations 615 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 616 . 618 Author's Address 620 Susan Hares 621 Huawei 622 7453 Hickory Hill 623 Saline, MI 48176 624 USA 626 Email: shares@ndzh.com