idnits 2.17.1 draft-wang-sfc-receive-only-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Extended SFC Proxy MUST discard any packets from the RO SF to prevent duplicated packets to the SFF. When preserved, the NSH SPID/ SI in the packet copy sent to RO SF MUST not change. The NSH SI in the original packet forwarded back to the SFF MUST be decremented. -- The document date (June 28, 2017) is 2494 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IDS' is mentioned on line 442, but not defined == Missing Reference: 'PC' is mentioned on line 209, but not defined == Missing Reference: 'FC' is mentioned on line 215, but not defined == Missing Reference: 'SF-2' is mentioned on line 270, but not defined == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 == Outdated reference: A later version (-03) exists of draft-wang-sfc-ns-use-cases-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining E. Wang 3 Internet-Draft K. Leung 4 Intended status: Informational Cisco Systems Inc. 5 Expires: December 30, 2017 June 28, 2017 7 Receive-Only Service Function and External Service in SFC 8 draft-wang-sfc-receive-only-02 10 Abstract 12 A category of services such as Intrusion Detection Service and Packet 13 Capture operates in "receive-only" mode. They are "packet sinks" 14 which consume all packets sent to them. This document describes the 15 proposals for such service to be part of the Service Function 16 Chaining framework. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 30, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3 55 3. Receive-Only Service Function vs. External Service . . . . . 3 56 4. SFC Packet Plane . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. Receive-Only Service Function . . . . . . . . . . . . . . 6 58 4.2. Receive-Only External Service . . . . . . . . . . . . . . 9 59 5. SFC Control Plane . . . . . . . . . . . . . . . . . . . . . . 12 60 5.1. Receive-Only Service Function . . . . . . . . . . . . . . 12 61 5.2. Receive-Only External Service . . . . . . . . . . . . . . 12 62 6. SFC Element Considerations . . . . . . . . . . . . . . . . . 13 63 6.1. Receive-Only Service Function . . . . . . . . . . . . . . 13 64 6.2. Extended SFC Proxy . . . . . . . . . . . . . . . . . . . 14 65 6.3. Receive-Only External Service . . . . . . . . . . . . . . 14 66 6.4. Service Function Forwarder . . . . . . . . . . . . . . . 14 67 6.4.1. Receive-Only Service Function . . . . . . . . . . . . 14 68 6.4.2. Receive-Only External Service . . . . . . . . . . . . 14 69 6.4.3. SFF Capabilities Considerations . . . . . . . . . . . 15 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 75 10.2. Informative References . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 Services in Service Function Chaining (SFC) usually operate in 81 "inline" mode, where they process the received packets and return the 82 packets to the Service Function Forwarder (SFF). Some services 83 especially in the network security domain can buffer, inject or block 84 certain packets, as well as proxy entire connections 85 ([I-D.wang-sfc-ns-use-cases]). However, in general they still 86 forward packets. 88 [I-D.wang-sfc-ns-use-cases] also describes a special set of services 89 that consume all packets sent to them. We refer to such behavior as 90 "receive-only". A receive-only service could be a Service Function 91 (SF) participating in SFC ([RFC7665]), or it could be an External 92 Service (ES) receiving packets from the SFF or another regular SF. 93 This document describes proposals for designing SFC packet plane and 94 control plane to incorporate receive-only services. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Definition Of Terms 104 This document uses the terms as defined in [RFC7498], [RFC7665] and 105 [I-D.ietf-sfc-nsh]. 107 In addition the following terms are defined. 109 Receive-Only (RO): A service operational mode where the service does 110 not forward on packets that it receives. It is often known as 111 "packet sink" as well. 113 RO SF: A Receive-Only Service Function participating in SFC as 114 defined in [RFC7665], except that the SF operates in Receive-Only 115 mode. 117 RO ES: A Receive-Only External Service not participating in SFC. 118 Specifically, an RO ES is not an SF. It is not allocated with a 119 Service Index (SI) in the Service Function Path (SFP). However, 120 it receives packets from the SFF or an SF. 122 Extended SFC Proxy: An SFC Proxy ([RFC7665]) with extended 123 capability to support Receive-Only SF. The SFC Proxy replicates 124 and sends packets to the RO SF. The SFC encapsulation may be 125 preserved if the RO SF is SFC aware. The Proxy forwards the 126 original packets back to the SFF in the same way as a regular SF 127 (e.g., with Service Index (SI) decremented in NSH). 129 Flow: A unidirectional traffic stream identified by network layer 130 attributes, specifically IP addresses and TCP/UDP ports for TCP/ 131 UDP traffic. 133 Connection: A bidirectional traffic stream composed of two flows 134 sharing the same network layer attributes. 136 3. Receive-Only Service Function vs. External Service 138 A receive-only service may be a Service Function (SF) or External 139 Service (ES) depending on whether the SFC administrator designs the 140 service to be part of the SFC or not. 142 In the following example, the IDS service is located between "DDoS 143 Mitigator" and "Firewall" as part of an integrated security solution 144 to protect the server (S). Packets from the client (C) must be 145 examined by a chain of services before they reach the server. The 146 three service functions, DDoS, IDS and Firewall, compose an SFC. 147 Each SF including the IDS SF is allocated with a Service Index (SI) 148 in the SFP. The IDS SF is a fundamental part of the service chain 149 with the only exception that it does not egress packets. We refer to 150 the IDS service as a Receive-Only SF (RO SF). 152 There are other attributes for an RO SF. There is a limited number 153 of location options for "IDS" to be deployed in an SFC. Once 154 deployed, the location of "IDS" does not change usually unless the 155 SFs are added to or removed from the SFC. 157 Extending the SFC framework to RO SF enables a common SFC policy 158 model for SFC administrators. The administrator only needs to manage 159 one set of policy that covers both RO and regular SFs, no matter how 160 they handle packets. 162 .---. .---. .-------. 163 / \ / \ / \ 164 ( DDoS ) ( [IDS] ) ( Firewall ) 165 \ / \ / \ / 166 `-+-' `-+-' `---+---' 167 /|\ /|\ /|\ 168 | | copy | 169 +---+ \|/ | \|/ +---+ 170 | | ,--+-----------+-------------+----. | | 171 | C +----( SFF )----+ S | 172 | | `---------------------------------' | | 173 +---+ +---+ 174 SFC - DDoS : [IDS] : Firewall 176 [ ] denotes receive-only 178 Figure 1: Receive-Only Service Function (RO SF) example 180 "Packet Capture" for troubleshooting represents the other type of 181 receive-only services that do not participate in SFC. 183 The administrator may insert "Packet Capture" at any stage of an SFP. 184 Packets may be captured before and/or after one or multiple SFs, 185 which means there are many possible invocation points for "Packet 186 Capture" in an SFP. The administrator may want to dynamically insert 187 or remove "Packet Capture" based on the need for troubleshooting and 188 threat analysis. When doing so, it is desired that the construction 189 of the SFP is not affected. That is, the Service Path ID (SPID) and 190 Service Index (SI) for each of the SFs in the SFP remain unchanged. 192 Services with the above attributes receive SFC packets but are not 193 listed in an SFC. They do not consume an SI in the SFP. We refer to 194 such a service as a Receive-Only External Service (RO ES). 196 An RO ES still requires support from SFC elements including SFF and 197 SF for receiving packets. Because an RO ES does not send back 198 packets, it must receive replication of the packets. Depending on 199 the use cases and performance requirements, an SFF or SF may perform 200 the packet replication for the RO ES. For example, a Packet Capture 201 for troubleshooting purpose may tap on the SFF at one or more 202 locations along the SFP (Figure 2). 204 This document describes the necessary enhancements to the SFC 205 framework for supporting RO ES. 207 +------+ 208 copy | | copy 209 ...\....| [PC] |.../....... 210 . / | | \ . 211 . _.+------+ . 212 . .| . 213 . . copy +------+ . 214 . . | | . 215 . . | [FC] | . 216 . . | | . 217 . . _.+------+ . 218 . . .| . 219 . . . copy . 220 . . . . 221 . .---. . .----+--. .---. . 222 . / \ . / \ / \ . 223 . ( DDoS ) . ( Firewall ) ( WAF ) . 224 . \ / . \ / \ / . 225 . `-+-' . `---+---' `-+-' . 226 . /|\ . /|\ /|\ . 227 . | . | | . 228 +---+ . \|/ . \|/ \|/ . +---+ 229 | | ,+-----+-----+-------+-------------+-----+--. | | 230 | C +----( SFF )----+ S | 231 | | `-------------------------------------------' | | 232 +---+ +---+ 233 SFC - DDoS : Firewall : WAF 235 [ ] denotes receive-only 237 PC: Packet Capture 238 FC: File Capture 240 Figure 2: Receive-Only External Service (RO ES) examples 242 4. SFC Packet Plane 244 4.1. Receive-Only Service Function 246 A Receive-Only SF behaves the same way as a regular SF except that it 247 does not forward packets. As a result, it must receive a copy of the 248 packets while the original packets travel through the rest of the SFs 249 in the SFP. Because an RO SF occupies an SI in the SFP, the SI of 250 the original packet must be decremented after the packet passes the 251 RO SF. 253 Considering the fact that an RO SF does not forward packets and SFF 254 is not designed to decrement SI, an Extended SFC Proxy is leveraged 255 to perform the packet replication and SI decrement tasks on behalf of 256 the RO SF. As shown in the Figure below, the Extended SFC Proxy 257 makes a copy of the packet including the NSH and sends the copy to 258 the RO SF-2. It decrements the SI of original packet and forwards 259 that packet back to the SFF. This capability is an extension to the 260 current SFC Proxy as defined in ([RFC7665]). 262 From the SFF's perspective, the combination of the Extended SFC Proxy 263 and the RO SF behaves as a regular SF that processes and forwards 264 packets with SI decremented. From the RO SF's perspective, the 265 Extended SFC Proxy may be a logical component in the specific SFF 266 implementation for efficiency. 268 .---. .---. .---. 269 / \ / \ / \ 270 ( SF-1 ) ( [SF-2]) ( SF-3 ) 271 \ / \ / \ / 272 `-+-' `-+-' `-+-' 273 | /.\ /|\ 274 | . (3) | 275 | . SPID:10 | 276 | . SI:254 | 277 | . | 278 | . [copy] | 279 (1) | . |(5) 280 SPID:10| ,-----+-----. |SPID:10 281 SI:254 | ( Extended ) |SI:253 282 | ( SFC Proxy ) | 283 | ( ) | 284 | ( Replicator ) | 285 | `---+---+---' | 286 | /|\ |(4) | 287 | (2) | |SPID:10 | 288 | SPID:10| |SI:253 | 289 \|/ SI:254 | \|/ | 290 ,----+----------+---+-----------+------. 291 ( : : : : ) 292 ( : +---+ : : +---+ : ) 293 ( : | | : : | | : ) 294 ( :..+FWD+...: :...+FWD+...: ) 295 ( | | | | ) 296 ( +---+ +---+ ) 297 ( SFF ) 298 `--------------------------------------' 300 FWD: Forwarding Table Lookup 302 Figure 3: Packet Replication and SI Decrement by Extended SFC Proxy 303 for RO SF 305 A packet goes through the following steps in the above example: 307 1. SFF receives the packet from SF-1 with SPID=10 and SI=254 309 2. SFF looks up in its forwarding table and finds Extended SFC Proxy 310 for SF-2 to be the next hop. SFF sends the packet to SF-2's 311 Proxy. 313 3. Extended SFC Proxy replicates the packet and sends the copy to 314 SF-2 which is an RO SF. The copy has SI=254 316 4. Extended SFC Proxy decrements the SI of the original packet and 317 sends the packet back to SFF. The packet now has SI=253 319 5. SFF looks up the next service function, SF-3, in its forwarding 320 table based on the SPID and SI from Extended SFC Proxy. SFF 321 sends the packet to SF-3. 323 4.2. Receive-Only External Service 325 A Receive-Only External Service still receives a copy of the packets 326 designated to it even if it is not listed in the SFP. 328 For some use cases such as capturing a file content for sandbox 329 analysis, packet data replication may be conducted by an SF capable 330 of identifying file boundary in the packet stream. The RO ES would 331 be associated with the SF and receives packet data from the SF 332 directly. 334 Alternatively, for use cases such as generic packet capture for 335 troubleshooting, the SFF may carry out the packet replication and 336 forwarding work. Higher performance may be achieved with hardware 337 based SFF. 339 +-------+ +-------+ 340 | | | | 341 | [ES-1]| .| [ES-1]|. 342 | | . | | . 343 +---+---+ _. +---+---+ ._ 344 . . .| /.\ |.copy 345 . . . copy .copy . 346 _. ._ . . . 347 .| |.copy . . . 348 . copy . . . . 349 . . . . . 350 .---. .---. . .---. . .---. . 351 / \ / \ . / \ . / \ . 352 ( SF-1 ) ( SF-2 ) . ( SF-1 ) . ( SF-2 ) . 353 \ / \ / . \ / . \ / . 354 `-+-' `-+-' . `-+-' . `-+-' . 355 /|\ /|\ . /|\ . /|\ . 356 | | . | . | . 357 \|/ \|/ . \|/ . \|/ . 358 ,-------+--------------+-------. ,-+-----+------+------+-----+-. 359 ( SFF ) ( SFF ) 360 `------------------------------' `-----------------------------' 362 (a) Copy by SF (b) Copy by SFF 364 Figure 4: Packet replication options for RO ES 366 When an RO ES receives packets from the SFF, it may be attached to 367 the SFF at multiple locations along the SFP. The location may be 368 indicated by a (SPID, SI) pair and programmed into the SFF's 369 forwarding table. 371 The SFF performs packet replication when the packet needs to be sent 372 to the RO ES (SFC Proxy cannot be used because RO ES is not an SF). 373 The SI of the original packet MUST NOT be affected by the fact that a 374 copy is being sent to the RO ES. The following figure illustrates an 375 example with SFF performing packet replication. 377 +-------+ 378 | | 379 | [ES-1]| 380 | | 381 +---+---+ 382 /.\ 383 .---. . .---. 384 / \ . / \ 385 ( SF-1 ) . ( SF-2 ) 386 \ / . \ / 387 `-+-' . `-+-' 388 | . /|\ 389 | .(2) | 390 |(1) .SPID:10 |(3) 391 |SPID:10 .SI:254 |SPID:10 392 |SI:254 . |SI:254 393 | .[copy] | 394 \|/ . | 395 ,----+-----------+-----------+------. 396 ( : : : ) 397 ( : +--+--+ : ) 398 ( : | REP | : ) 399 ( : +---+ +--+--+ : ) 400 ( : | | : : ) 401 ( :.+FWD+.....:...........: ) 402 ( | | ) 403 ( +---+ ) 404 ( SFF ) 405 `-----------------------------------' 407 FWD: Forwarding Table Lookup 408 REP: Packet Replication 410 Figure 5: Packet Replication by SFF for RO ES 412 Here is a sample packet flow involving an Receive-Only External 413 Service: 415 1. SFF receives the packet from SF-1 with SPID=10 and SI=254 417 2. SFF looks up the next service function, SF-2, in its forwarding 418 table. The forwarding entry also indicates an RO ES at this 419 location. SFF replicates the packet and sends a copy of the 420 packet including NSH to ES-1. The original packet is not 421 changed. 423 3. SFF sends the original packet to SF-2. 425 5. SFC Control Plane 427 5.1. Receive-Only Service Function 429 An RO SF such as IDS is specified the same way as a regular SF in the 430 SFC Classification Policy. For example, the SFC in Figure 1 contains 431 the following SFs: 433 SFC - DDoS : [IDS] : Firewall 435 When the SFC is converted to an SFP, the combination of Extended SFC 436 Proxy and the IDS RO SF presents as a regular SF in the SFP as 437 depicted in Figure 3. The SFP comprises of the following: 439 SFP - DDoS : SFC Proxy for [IDS] : Firewall 441 The SFC Control Plane also provisions the Extended SFC Proxy to send 442 the replicated packet to the [IDS] SF. The provisioning message is 443 outside the scope of this document. 445 5.2. Receive-Only External Service 447 An RO ES is not provisioned by SFC Classification Policy. 448 Implementation may choose to use a dedicated policy for an RO ES such 449 as "Packet Capture Policy". 451 The policy for RO ES may be configured into a regular SF when the SF 452 performs replication for the RO ES. 454 In the scenario where SFF performs packet replication, the RO ES 455 policy may be evaluated by the SFC Control Plane. The SFC Control 456 Plane programs the replication locations into the SFF, as indicated 457 by (SPID, SI) pairs. Figure 6 below illustrates a control plane flow 458 for setting packet replication in the SFF for an RO ES. 460 +-------------------+ 461 | | 462 | SFC Control Plane | 463 | | 464 | .--. | 465 | (1) : : | 466 | |'--'| | 467 | RO-ES | | | 468 | Policy| | | 469 | Eval '--' | 470 | | 471 +------+------------+ Control Plane 472 .........|................................ 473 | 474 | +-------+ Packet Plane 475 | | | 476 | | RO ES | 477 |(2) | | 478 | +---+---+ 479 |C2 /:\ 480 | :packet 481 | :copy 482 v : 483 ,--+---------+--+--+--. 484 ( | REP | ) 485 ( SFF +-----+ ) 486 ( ) 487 `---------------------' 489 Figure 6: Control flow for SFF replication for RO ES 491 1. SFC Control Plane evaluates the RO ES policy and determines the 492 location(s) for SFF to perform packet replication and send 493 packets to RO ES. 495 2. SFC Control Plane uses C2 Control Plane-SFF interface 496 ([I-D.ietf-sfc-control-plane]) to update the SFF forwarding table 497 with replication entries to RO ES. 499 6. SFC Element Considerations 501 6.1. Receive-Only Service Function 503 An RO SF MUST NOT send received packets back to the Extended SFC 504 Proxy. 506 6.2. Extended SFC Proxy 508 The Extended SFC Proxy for an RO SF carries the following additional 509 capabilities compared with a regular SFC Proxy: 511 1. Packet replication 513 2. Preserving the SFC encapsulation in the copy of the packet when 514 the RO SF is SFC aware 516 The Extended SFC Proxy MUST discard any packets from the RO SF to 517 prevent duplicated packets to the SFF. When preserved, the NSH SPID/ 518 SI in the packet copy sent to RO SF MUST not change. The NSH SI in 519 the original packet forwarded back to the SFF MUST be decremented. 521 6.3. Receive-Only External Service 523 An RO ES should have proper transport with the data source, either 524 the SF or SFF. If it receives replicated packets from the SFF, the 525 RO ES should comply with the transport as specified for the SFC, 526 similar to that between a regular SF and the SFF. 528 An RO ES MUST NOT send received packets back to the data source. 530 6.4. Service Function Forwarder 532 6.4.1. Receive-Only Service Function 534 There is not any special requirement for the SFF to support an RO SF. 535 The Extended SFC Proxy performs packet replication and other regular 536 SF tasks on behalf of the RO SF. 538 6.4.2. Receive-Only External Service 540 The following figure illustrates a sample SFF forwarding table when 541 the SFF carries out the packet replication task for RO ES. The 542 "copy" column in the forwarding table is used to decide whether a 543 copy or the original packet should be sent to the next hop (SF or 544 ES). Entries for the RO ES have the "copy" field set. 546 SFF Forwarding Entries 547 +------+------+------+------+ 548 | SPID | SI | Next | Copy | 549 | | | Hop | | 550 +------+------+------+------+ 551 | ... | | | | 552 +------+------+------+------+ 553 | | | SF-1 | | 554 | 10 | 254 +------+------+ 555 | | | ES-1 | x | 556 +------+------+------+------+ 557 | 10 | 253 | SF-2 | | 558 +------+------+------+------+ 559 | 20 | 254 | SF-1 | | 560 +------+------+------+------+ 561 | | | SF-3 | | 562 | 20 | 253 +------+------+ 563 | | | ES-2 | x | 564 +------+------+------+------+ 565 | 20 | 252 | SF-4 | | 566 +------+------+------+------+ 567 | ... | | | | 568 +------+------+------+------+ 570 Figure 7: Sample SFF forwarding table with RO ES entries 572 6.4.3. SFF Capabilities Considerations 574 In order to support RO ES, implementation of an SFF SHOULD support 575 the following capabilities: 577 1. Packer replication 579 2. Discarding any packets returned by an RO ES 581 Additional capabilities for receive-only support include the 582 following: 584 1. Replicating a portion of the packet (e.g. headers only) 586 2. Filtering selected packets to be replicated to receive-only 587 service 589 3. Sending collective statistics in place of raw packet data 591 4. Producing Netflow/IPFIX and other events 593 Those capabilities are beyond the scope of this document. 595 7. Security Considerations 597 Even if an RO SF is required not to send packets back to the Extended 598 SFC Proxy, the implementation of Extended SFC Proxy SHOULD handle 599 packets from an RO SF gracefully without causing exceptions or 600 duplicated packets in the SFP. 602 8. Acknowledgments 604 Authors would like to thank Jeremy Felix and Jay Iyer for their 605 contributions, and Jim Guichard, Paul Quinn and Joel Halpern for 606 their review and comments. 608 9. IANA Considerations 610 This document includes no request to IANA. 612 10. References 614 10.1. Normative References 616 [I-D.ietf-sfc-control-plane] 617 Boucadair, M., "Service Function Chaining (SFC) Control 618 Plane Components & Requirements", draft-ietf-sfc-control- 619 plane-08 (work in progress), October 2016. 621 [I-D.ietf-sfc-nsh] 622 Quinn, P. and U. Elzur, "Network Service Header", draft- 623 ietf-sfc-nsh-12 (work in progress), February 2017. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 631 Service Function Chaining", RFC 7498, 632 DOI 10.17487/RFC7498, April 2015, 633 . 635 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 636 Chaining (SFC) Architecture", RFC 7665, 637 DOI 10.17487/RFC7665, October 2015, 638 . 640 10.2. Informative References 642 [I-D.wang-sfc-ns-use-cases] 643 Wang, E., Leung, K., Felix, J., and J. Iyer, "Service 644 Function Chaining Use Cases for Network Security", draft- 645 wang-sfc-ns-use-cases-02 (work in progress), October 2016. 647 Authors' Addresses 649 Eric Wang 650 Cisco Systems Inc. 651 170 W Tasman Dr 652 San Jose, CA 95134 653 U.S.A. 655 Email: ejwang@cisco.com 657 Kent Leung 658 Cisco Systems Inc. 659 170 W Tasman Dr 660 San Jose, CA 95134 661 U.S.A. 663 Email: kleung@cisco.com