idnits 2.17.1 draft-ietf-sfc-control-plane-08.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 (October 23, 2016) is 2741 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-09 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-05 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining (sfc) M. Boucadair, Ed. 3 Internet-Draft Orange 4 Intended status: Informational October 23, 2016 5 Expires: April 26, 2017 7 Service Function Chaining (SFC) Control Plane Components & Requirements 8 draft-ietf-sfc-control-plane-08 10 Abstract 12 This document describes requirements for conveying information 13 between Service Function Chaining (SFC) control elements and SFC data 14 plane functional elements. Also, this document identifies a set of 15 control interfaces to interact with SFC-aware elements to establish, 16 maintain or recover service function chains. This document does not 17 specify protocols nor extensions to existing protocols. 19 This document exclusively focuses on SFC deployments that are under 20 the responsibility of a single administrative entity. Inter-domain 21 considerations are out of scope. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 26, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Generic Considerations . . . . . . . . . . . . . . . . . . . 6 62 2.1. Generic Requirements . . . . . . . . . . . . . . . . . . 6 63 2.2. SFC Control Plane Bootstrapping . . . . . . . . . . . . . 6 64 2.3. SFC Dynamics . . . . . . . . . . . . . . . . . . . . . . 7 65 2.4. Coherent Setup of an SFC-enabled Domain . . . . . . . . . 8 66 3. SFC Control Plane: Reference Architecture & Interfaces . . . 8 67 3.1. Reference Architecture . . . . . . . . . . . . . . . . . 8 68 3.2. Centralized vs. Distributed . . . . . . . . . . . . . . . 10 69 3.3. Interface Reference Points . . . . . . . . . . . . . . . 11 70 3.3.1. C1: Interface between SFC Control Plane & SFC 71 Classifier . . . . . . . . . . . . . . . . . . . . . 11 72 3.3.2. C2: Interface between SFC Control Plane & SFF . . . . 13 73 3.3.3. C3: Interface between SFC Control Plane & SFC-aware 74 SFs . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 3.3.4. C4: Interface between SFC Control Plane & SFC Proxy . 16 76 4. Additional Considerations . . . . . . . . . . . . . . . . . . 16 77 4.1. Discovery of the SFC Control Element . . . . . . . . . . 16 78 4.2. SF Symmetry . . . . . . . . . . . . . . . . . . . . . . . 17 79 4.3. Pre-deploying SFCs . . . . . . . . . . . . . . . . . . . 17 80 4.4. Withdraw a Service Function (SF) . . . . . . . . . . . . 17 81 4.5. SFC/SFP Operations . . . . . . . . . . . . . . . . . . . 18 82 4.6. Unsolicited (Notification) Messages . . . . . . . . . . . 18 83 4.7. Liveness Detection . . . . . . . . . . . . . . . . . . . 18 84 4.8. Monitoring & Counters . . . . . . . . . . . . . . . . . . 19 85 4.9. Validity Lifetime . . . . . . . . . . . . . . . . . . . . 19 86 4.10. Considerations Specific to the Centralized Path 87 Computation Model . . . . . . . . . . . . . . . . . . . . 20 88 4.10.1. Service Function Path Adjustment . . . . . . . . . . 20 89 4.10.2. Head End Initiated SFP Establishment . . . . . . . . 21 90 4.10.3. (Regional) Restoration of Service Functions . . . . 21 91 4.10.4. Fully Controlled SFF/SF Sequence for a SFP . . . . . 22 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 93 5.1. Secure Communications . . . . . . . . . . . . . . . . . . 23 94 5.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 24 95 5.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 5.4. Denial-of-Service (DoS) . . . . . . . . . . . . . . . . . 24 97 5.5. Illegitimate Discovery of SFs and SFC Control Elements . 24 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 100 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 103 9.2. Informative References . . . . . . . . . . . . . . . . . 27 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 106 1. Introduction 108 The dynamic enforcement of a service-derived forwarding policy for 109 packets entering a network that supports advanced Service Functions 110 (SFs) has become a key challenge for operators. Typically, many 111 advanced Service Functions (e.g., Performance Enhancement Proxies 112 ([RFC3135]), NATs [RFC3022][RFC6333][RFC6146], firewalls 113 [I-D.ietf-opsawg-firewalls], etc.) are solicited for the delivery of 114 value-added services, particularly to meet various service objectives 115 such as IP address sharing, avoiding covert channels, detecting and 116 protecting against ever increasing Denial-of-Service (DoS) attacks, 117 etc. 119 Because of the proliferation of such advanced service functions 120 together with complex service deployment constraints that demand more 121 agile service delivery procedures, operators need to rationalize 122 their service delivery logics and master their complexity while 123 optimising service activation time cycles. The overall problem space 124 is described in [RFC7498]. A more in-depth discussion on use cases 125 can be found in [I-D.ietf-sfc-use-case-mobility] and 126 [I-D.ietf-sfc-dc-use-cases]. 128 [RFC7665] presents a model addressing the problematic aspects of 129 existing service deployments, including topological dependence and 130 configuration complexity. It also describes an architecture for the 131 specification, creation, and ongoing maintenance of Service Function 132 Chains (SFC) within a network. That is, how to define an ordered set 133 of Service Functions and ordering constraints that must be applied to 134 packets and/or frames and/or flows selected as a result of 135 classification. [I-D.ietf-sfc-nsh] specifies the SFC encapsulation 136 as per [RFC7665]. 138 1.1. Scope 140 While [RFC7665] focuses on data plane considerations, this document 141 describes requirements for conveying information between SFC control 142 elements and SFC data plane functional elements. Also, this document 143 identifies a set of control interfaces to interact with SFC-aware 144 elements to establish, maintain or recover service function chains. 146 Both distributed and centralized control plane schemes to install 147 SFC-related state and influence forwarding policies are discussed. 149 This document does not make any assumption on the deployment use 150 cases. In particular, the document implicitly covers fixed, mobile, 151 data center networks, and any combination thereof. 153 This document does not make any assumption about which control 154 protocol to use, whether one or multiple control protocols are 155 required, or whether the same or distinct control protocols will be 156 invoked for each of the control interfaces. It is out of scope of 157 this document to specify a profile for an existing protocol, to 158 define protocol extensions, or to select a protocol. 160 Considerations related to the chaining of Service Functions (SFs) 161 that span domains owned by multiple administrative entities are out 162 of scope. 164 It is out of scope of this document to discuss SF-specific control 165 and policy enforcement schemes; only SFC considerations are 166 elaborated, regardless of the various connectivity services that may 167 be supported in the SFC-enabled domain. Likewise, only the control 168 of SFC-aware elements is discussed. 170 Service catalogue (including guidelines for deriving service function 171 chains) is out of scope. 173 This document does not specify any flow exchange to illustrate the 174 comprehensive SFC operation. Instead, it focuses on the required 175 information to be conveyed via each control interface. Note that 176 sketching a comprehensive flow exchange is also a function of 177 deployment considerations that are out of scope. 179 1.2. Terminology 181 The reader should be familiar with the terms defined in [RFC7498] and 182 [RFC7665]. 184 The document makes use of the following terms: 186 o SFC data plane functional element: Refers to SFC-aware Service 187 Function, Service Function Forwarder (SFF), SFC proxy, or 188 classifier as defined in the SFC data plane architecture 189 [RFC7665]. 191 o SFC Control Element: A logical entity that instructs one or more 192 SFC data plane functional elements on how to process packets 193 within an SFC-enabled domain. 195 o SFC Classification rule: Refers to a rule maintained by a 196 classifier that reflects the policies for binding an incoming 197 flow/packet to a given SFC and Service Function Path (SFP). 198 Actions are associated with matching criteria. The set of 199 classification entries maintained by a classifier are referred to 200 as in the classification policy table. 202 o SFP Forwarding Policy Table: this table reflects the SFP-specific 203 traffic forwarding policy enforced by SFF components for every 204 relevant incoming packet that is associated to one of the existing 205 SFCs. The SFP Identifier (SFP-id) is used as a lookup key to 206 determine forwarding action regardless of whether the SFC is fully 207 constrained, partially constrained, or not constrained at all. 208 Additional information such as a flow identifier, Service Index 209 (SI), and/or other characteristics (e.g., the 5-tuple transport 210 coordinates of the original packet) may be used for lookup 211 purposes. The set of information to use for lookup purposes may 212 be instructed by the control plane. 214 1.3. Assumptions 216 This document adheres to the assumptions listed in Section 1.2 of 217 [RFC7665]. 219 As a reminder, a Service Function Path (SFP) designates a subset of 220 the collection designated by the SFC. For some SFPs, in some 221 deployments, that will be a set of 1. For other SFPs (in the same or 222 other deployments) it may be a larger set. For some SFPs in some 223 deployments the SFP may designate the same set of choices as the SFC. 224 This document accommodates all those deployments. 226 This document does not make any assumptions about the co-location of 227 SFC data plane functional elements; this is deployment-specific. 228 This document can accommodate a variety of deployment contexts such 229 as (but not limited to): 231 o A Service Function Forwarder (SFF) can connect instances of the 232 same or distinct SFs. 233 o An SF instance can be serviced by one or multiple SFFs. 234 o One or multiple SFs can be co-located with an SFF. 235 o A boundary node (that connects one SFC-enabled domain to a node 236 either located in another SFC-enabled domain or in a domain that 237 is SFC-unaware) can act as an egress node and an ingress node for 238 the same flow. 239 o Distinct ingress and egress nodes may be crossed by a packet when 240 forwarded in an SFC-enabled domain. 241 o Distinct ingress nodes may be solicited for each traffic direction 242 (e.g., upstream and downstream). 244 o The same boundary node may act as an ingress node, an egress node, 245 and also embed a classifier. 246 o A classifier can be hosted in a node that embeds one or more SFs. 247 o Many network elements within an SFC-enabled domain may behave as 248 egress/ingress nodes. 250 Furthermore, the following assumptions are made: 252 o A Control Element can be co-located with a classifier, SFF or SF. 253 o One or multiple Control Elements can be deployed in an SFC-enabled 254 domain. 255 o State synchronization between Control Elements is out of scope. 257 2. Generic Considerations 259 2.1. Generic Requirements 261 Some deployments require that forwarding within an SFC-enabled domain 262 must be allowed even if no control protocols are enabled. Static 263 configuration must be allowed. 265 A permanent association between an SFC data plane element with a 266 Control Element must not be required; specifically, the SFC-enabled 267 domain must keep on processing incoming packets according to the SFC 268 instructions even during temporary unavailability events of control 269 plane components. SFC implementations that do not meet this 270 requirement will suffer from another flavor of the constrained high 271 availability issue, discussed in Section 2.3 of [RFC7498], supposed 272 to be solved by SFC designs. 274 2.2. SFC Control Plane Bootstrapping 276 The interface that is used to feed the SFC control plane with service 277 objectives and guidelines is not part of the SFC control plane 278 itself. Therefore, this document assumes the SFC control plane is 279 provided with a set of required information for proper SFC operation 280 with no specific assumption about how this information is collected/ 281 provisioned, nor about the structure of such information. The 282 following information that is recommended to be provided to the SFC 283 control plane prior to bootstrapping includes: 285 o Locators for classifiers/SFF/SFs/SFC proxies, etc. 286 o SFs serviced by each SFF. 287 o A list of service function chains, including how they are 288 structured and unambiguously identified. 289 o Status of each SFC: active/pre-deployment phase/etc. An SFC can 290 be defined at the management level and instantiated in an SFC- 291 enabled domain for pre-deployment purposes (e.g., testing). 293 Actions to activate, modify or withdraw an SFC are triggered by 294 the control plane. Nevertheless, this document does not make any 295 assumption about how an operator instructs the control plane. 296 o A list of classification guidelines and/or rules to bind flows to 297 SFCs/SFPs. 298 o Security credentials. 299 o Context information that needs to be shared on a per SFC basis. 301 Optionally, load balancing objectives at the SFC level or on a per 302 node (e.g., per-SF/SFF/SFC proxy) basis may also be provided to the 303 SFC control plane. Likewise, the set of metadata that is supported 304 by SFC-aware SFs, SFFs, and SFC proxies may be provided to the SFC 305 control plane. 307 Also, the SFC control plane may gather the following information from 308 an SFC-enabled domain at bootstrapping (non-exhaustive list). How 309 this information is collected is left unspecified in this document: 311 o The list of active SFC-aware SFs (including their locators). 312 o The list of SFFs and the SFs that are attached to. 313 o The list of enabled SFC proxies, and the list of SFC-unaware SFs 314 attached to. 315 o The list of active SFCs/SFPs as enabled in an SFC-enabled domain. 316 o The list of classifiers and their locators, so as to retrieve the 317 classification policy table for each classifier, in particular. 318 o The SFP Forwarding Policy Tables maintained by SFFs. 319 o The set of metadata that is supported by SFC-aware SFs, SFFs, and 320 SFC proxies. Additional capabilities (e.g., supported transport 321 encapsulation scheme(s), supported SFC header version(s)) may also 322 be collected. 324 During the bootstrapping phase, a Control Element may detect a 325 conflict between the running configuration in an SFC data plane 326 element and the information maintained by the control plane. 327 Consequently, the control plane undertakes appropriate actions to fix 328 those conflicts. This is typically achieved by invoking one of the 329 interfaces defined in Section 3.3. 331 After bootstrapping, the SFC control plane is fed (dynamically or on 332 a per request basis) with a set of information that is required for 333 proper SFC operation. More details about this information are 334 discussed in Section 3 and Section 4. 336 2.3. SFC Dynamics 338 By default, SFC data and control plane elements must assume that SFC 339 control information are dynamic by nature. This requirement applies 340 even for policies that are communicated via an upper layer to 341 communicate service objectives and guidelines to a control element. 342 Additionally, the SFC control plane must not assume that the 343 capabilities of SFC data plane elements are frozen. The SFC control 344 architecture must be designed to accommodate any dynamic of SFs/SFFs 345 attachments, software updates, dynamic network condition events, etc. 347 The overall SFC orchestration is not discussed in this document 348 because SFC operations are likely to be policy-driven. Nevertheless, 349 the document specifies required interfaces that can be invoked in the 350 context of an SFC orchestration fed with policies that are local to 351 an SFC-enabled domain. No assumption is made about those policies 352 nor their change dynamics. The control interfaces are designed to 353 cover both dynamic control information exchange, but also to issue 354 request solicitations to the appropriate SFC data plane elements. 356 2.4. Coherent Setup of an SFC-enabled Domain 358 Various transport encapsulation schemes and/or versions of SFC header 359 implementations may be supported by one or several nodes of an SFC- 360 enabled domain. For the sake of coherent configuration, the SFC 361 control plane is responsible for instructing all the involved SFC 362 data plane functional elements about the behavior to adopt to select 363 the transport encapsulation scheme(s), the version of the SFC header 364 to enable, etc. 366 3. SFC Control Plane: Reference Architecture & Interfaces 368 3.1. Reference Architecture 370 The SFC control plane is responsible for the following: 372 o Build and monitor the service-aware topology. For example, this 373 can be achieved by means of dynamic SF discovery techniques. 374 Those means are out of scope of this document. 375 o Maintain a repository of service function chains, SFC matching 376 criteria to bind flows to a given service function chain, and 377 mapping between service function chains and SFPs. 378 o Guarantee the coherency of the configuration and the operation of 379 an SFC-enabled domain. 380 o Dynamically compute a service forwarding path (distributed model, 381 see Section 3.2). 382 o Determine a forwarding path in the context of a centralized 383 deployment model (see Section 3.2). 384 o Update service function chains or adjust SFPs (e.g., for 385 restoration purposes) based on various inputs (e.g., external 386 policy context, path alteration, SF unavailability, SF withdrawal, 387 service decommissioning, etc.). 389 o Provision SFP Forwarding Policy Tables of involved SFFs and 390 provide classifiers with traffic classification rules. 392 +----------------------------------------------+ 393 | | 394 | SFC Control Plane | 395 +-------| | 396 | | | 397 C1 +------^-----------^-------------^-------------+ 398 +---------------------|C3---------|-------------|-------------+ 399 | | +----+ | | | 400 | | | SF | |C2 |C2 | 401 | | +----+ | | | 402 | +----V--- --+ | | | | 403 | | SFC | +----+ +-|--+ +----+ | 404 | |Classifier |---->|SFF |----->|SFF |------->|SFF | | 405 | | Node |<----| |<-----| |<-------| | | 406 | +-----------+ +----+ +----+ +----+ | 407 | | | | | 408 | |C2 ------- | | 409 | | | | +-----------+ C4 | 410 | V +----+ +----+ | SFC Proxy |--> | 411 | | SF | |SF | +-----------+ | 412 | +----+ +----+ | 413 | |C3 |C3 | 414 | SFC Data Plane Components V V | 415 +-------------------------------------------------------------+ 417 Figure 1: SFC Control Plane Interfaces 419 Figure 1 shows the overall SFC control plane architecture, including 420 interface reference points. Particularly, Figure 1 shows the various 421 interfaces that are required for conveying control information 422 between the SFC control plane and underlying SFC data plane elements: 424 1. Interface between SFC Control Plane & SFC classifier (C1): This 425 interface is used to manage SFC classification rules in 426 classifiers. These rules can be added, modified, or deleted. 427 Additional information is provided in Section 3.3.1. In order to 428 avoid stale classification rules and to allow for local sanity 429 checks, a validity lifetime is associated with each 430 classification rule (Section 4.9). 432 2. Interface between SFC Control Plane & SFF (C2): This interface is 433 used to communicate with an SFF for various purposes (e.g., 434 communicate required information for SFC forwarding decision- 435 making, collect state information to adjust SFPs, collected 436 connected SFs, etc.). Section 3.3.2 specifies such interface. 438 3. Interface between SFC Control Plane & SFC-aware SFs (C3): The SFC 439 control plane uses this interface to interact with SFC-aware SFs. 440 This interaction may be direct or via dedicated SF management 441 systems (Section 3.3.3). 443 4. Interface between SFC Control Plane & SFC proxy (C4): The SFC 444 control plane uses this interface to interact with an SFC proxy 445 to communicate SFC instructions and to retrieve state information 446 required, e.g., for dynamic SFP adjustments (Section 3.3.4). 448 This document does not elaborate on the internal decomposition of the 449 SFC control plane functional blocks. The components within the SFC 450 control plane and their interactions are out of scope. 452 Note, the SFC control plane must be able to invoke SFC OAM 453 mechanisms, and to determine the results of OAM operations. 455 3.2. Centralized vs. Distributed 457 The SFC control plane can be (logically) centralized, distributed or 458 a combination thereof. Whether one or multiple SFC Control Elements 459 are enabled is deployment-specific. Nevertheless, the following 460 comments can be made: 462 SFC management (including SFC monitoring and supervision): is likely 463 to be centralized. 465 SFC mapping rules: i.e., service instructions to bind a flow to a 466 service function chain and SFP are likely to be managed by a 467 central SFC Control Element, but the resulting policies can be 468 shared among several Control Elements. Note, these policies can 469 be complemented with local information (e.g., an IPv4 address/IPv6 470 prefix assigned to a customer) because such information may not be 471 available to the central entity but known only during network 472 attachment phase. 474 Path computation: can be either distributed or centralized. 475 Distributed path computation means that the selection of the exact 476 sequence of SFs that a packet needs to invoke (along with 477 instances and/or SFF locator information) is a result of a 478 distributed path selection algorithm executed by involved nodes. 479 For some traffic engineering proposes, the SFP may be constrained 480 by the control plane; as such, some SFPs can be fully specified 481 (i.e., list all the SFF/SFs that need to be solicited) or 482 partially specified (e.g., exclude some nodes, explicitly select 483 which instance of a given SF needs to be invoked, etc.). 485 SFP resiliency (including restoration) refers to mechanisms to 486 ensure high available service function chains. It includes means 487 to detect node/link/path failures. Both centralized and 488 distributed mechanism to ensure SFP resiliency can be envisaged. 490 Implementing a (logically) centralized path computation engine 491 requires information to be dynamically communicated to the central 492 SFC Control Element, such as the list of available SF instances, SFF 493 locators, load status, SFP availability, etc. 495 3.3. Interface Reference Points 497 The following sub-sections describe the interfaces between the SFC 498 control plane, as well as various SFC data plane elements. 500 3.3.1. C1: Interface between SFC Control Plane & SFC Classifier 502 As a reminder, a classifier is a function that is responsible for 503 classifying traffic based on (pre-defined) rules. 505 This interface is used to install SFC classification rules in 506 classifiers. Once classification rules are populated, classifiers 507 are responsible for binding incoming traffic to service function 508 chains and SFPs according to these classification rules. Note, the 509 SFC control plane must not make any assumption on how the traffic is 510 to be bound to a given service function chain. In other words, 511 classification rules are deployment-specific. For instance, 512 classification can rely on a subset of the information carried in a 513 received packet such as 5-tuple classification, be subscriber-aware, 514 be driven by traffic engineering considerations, or any combination 515 thereof. Installing classification rules must be immediate. The 516 status of enforcing such rules must be communicated to the control 517 plane as part of the communication procedure. In particular, 518 specific error codes must be returned to the Control Element in case 519 an error is encountered during the enforcement procedure. 521 The SFC control plane should be responsible for removing invalid (and 522 stale) mappings from the classification tables maintained by the 523 classifiers. Also, local sanity checks mechanisms may be supported 524 locally by the classifiers, but those are out of scope. 526 The classifier may be notified (regularly or upon eventual change) by 527 the control plane about the available SFs (including the SFFs they 528 are attached to) or be part of the service function discovery 529 procedure. 531 Classification rules may be updated, deleted or disabled by the 532 control plane. Criteria that would trigger those operations are 533 deployment-specific. 535 This interface is also used to retrieve the list of classification 536 rules that are maintained by a classifier. This retrieval can be on 537 demand (at the initiative of the Control Element) or on a regular 538 basis (at the initiative of the classifier). 540 Given that service function chaining solutions may be applied to very 541 large sets of traffic, any control solution should take scaling 542 issues into consideration as part of the design. For example, 543 because a large number (e.g., 1000s) of classification entries may be 544 configured to a classifier, means to reduce classification lookup 545 time such as optimizing the size of the classification table (e.g., 546 by means of aggregation capabilities) should be supported by the SFC 547 control plane (and/or the classifier). 549 Below are listed some functional objectives that can be achieved 550 thanks to the invocation of this interface: 552 o Rationalize the management of classification rules. 553 o Maintain a global view of instantiated rules in all classifiers in 554 an SFC-enabled domain. 555 o Check the consistency of instantiated classification rules within 556 the same classifier or among multiple classifiers. 557 o Assess the impact of removing or modifying a classification rule 558 on packets entering an SFC-enabled domain. 559 o Aggregate classification rules for the sake of performance 560 optimization (mainly reduce lookup delays). 561 o Adjust classification rules when rules are based on volatile 562 identifiers (e.g., an IPv4 address, IPv6 prefix). 563 o Allow to rapidly restore SFC/SFP states during failure events that 564 occurred at a classifier (or a Control Element). 566 The control plane must instruct the classifier about the initial 567 values of the Service Index (SI). 569 Also, the control plane must instruct the classifier about the set of 570 metadata to be supplied in the context of a given chain. 572 SFC encapsulation protocol [I-D.ietf-sfc-nsh] includes metadata type 573 1 (MD#1) with mandatory context headers that can be used to convey 574 metadata along an SFP. [I-D.ietf-sfc-nsh] allows defining different 575 semantics in the context headers, but the NSH header does not convey 576 that semantics in the context header. [I-D.ietf-sfc-nsh] requires an 577 SFC-aware SF using the data placed in the MD#1 mandatory context 578 headers to use information external to the NSH data plane to 579 understand the semantics of the context data. Therefore, this 580 interface must provide such context semantics, including any suitable 581 scoping information. 583 The control plane must instruct the classifier whether it can trust 584 an existing SFC information carried in an incoming packet or whether 585 it must be ignored. 587 A classifier should send unsolicited messages through this interface 588 to notify the SFC control plane about specific events. Triggers for 589 sending unsolicited messages should be configurable parameter. 591 When re-classification is allowed in an SFC-enabled domain, this 592 interface can be used to control classifiers co-resident with SFC- 593 aware SFs, SFC proxies, or SFFs to manage re-classification rules. 595 When an incoming packet matches more than one classification rule, 596 tie-breaking criteria should be followed (e.g., priority). Such tie- 597 breaking criteria should be instructed by the control plane. 599 The identification of instantiated SFCs/SFPs is local to each 600 administrative domain; it is policy-based and deployment-specific. 602 3.3.2. C2: Interface between SFC Control Plane & SFF 604 SFFs make traffic forwarding decisions according to the entries 605 maintained in their SFP Forwarding Policy Table. Such table is 606 populated by the SFC control plane through the C2 interface. In 607 particular, this interface is used to instruct the SFF about the set 608 of information to use for lookup purposes (e.g., SFP-id, 5-tuple 609 transport coordinates). One or many entries may be installed using 610 one single control message. Installing new entries in the SFP 611 Forwarding Policy Table must be immediate. The status of enforcing 612 such entries must be communicated to the control plane as part of the 613 communication procedure. In particular, specific error codes must be 614 returned to the Control Element in case an error is encountered 615 during the enforcement procedure. 617 This interface is used to instruct an SFF about the SFC-aware SFs 618 that it can service. Such instruct typically occurs at the 619 bootstrapping of the SFF, in the event of a new SF is added to the 620 SFC-enabled domain, etc. 622 This interface is also used by the SFF to report the connectivity to 623 their attached (including embedded) SFs. Local means may be enabled 624 between the SFC-aware SFs and SFFs to allow for the dynamic 625 attachment of SFs to an SFF and/or discovery of SFs by an SFF but 626 those means are unspecified in this document. 628 The C2 interface is also used for collecting states of attributes 629 (e.g., availability, workload, latency), for example, to dynamically 630 adjust Service Function Paths. Such state can be collected using an 631 explicit request from a Control Element or by unsolicited 632 notification of the SFF on a regular basis or when an event occurs. 633 A configuration parameter should be supported by the SFF to instruct 634 the exact behavior to follow. 636 The C2 interface may be used to configure groups of functionally 637 equivalent SFs. In particular, this group may be used for load- 638 balancing purposes. 640 An SFF must be instructed to strip the SFC information for the chains 641 it terminates. Forwarding policies for handling packets bound to 642 chains that are terminated by an SFF may be communicated via this 643 interface. By default, an SFF relies on legacy processing for 644 forwarding these packets. 646 3.3.3. C3: Interface between SFC Control Plane & SFC-aware SFs 648 SFs may need to output some processing results of packets to the SFC 649 control plane. This information can be used by the SFC control plane 650 to update the SFC classification rules and the SFP Forwarding Policy 651 Table entries. 653 This interface is used to collect such kind of feedback information 654 from SFs. For example, the following information can be exchanged 655 between an SF and the SFC control plane: 657 o SF execution status: Some SFs may need to send information to the 658 control plane to fine tune SFPs. For example, a threat-detecting 659 SF can periodically send the threat characteristics via this 660 interface, such as high probability of threat with packet of a 661 given size. The control plane can then add an appropriate 662 matching criteria to SFF to steer traffic to a scrubbing center. 664 o SF load update: When SFs are under stress that yielded the 665 crossing of some performance thresholds, the SFC control plane 666 needs to be notified to adjust SFPs accordingly (especially when 667 the centralized path computation mode is enabled). It is out of 668 scope of this document to specify the exact methods to monitor the 669 performance threshold or stress level of SFs, nevertheless the SFC 670 control plane can invoke those methods for its operations. 672 o SF bypass: An SF may use this interface to notify the Control 673 Plane about its desire to be bypassed. The exact details about SF 674 bypass logic are out of scope of this document. 676 The SFC control needs the above status information for various tasks 677 it undertakes, but this information may be acquired directly from SFs 678 or indirectly from other management and control systems in the 679 operational environment. 681 This interface is used by an SFC-aware SF to report the set of 682 context information (a.k.a., metadata) that it supports and any 683 change of its capabilities, for example, as a result of a software 684 update. Such change notifications should be dynamic, by default. A 685 configuration parameter may be supported to disable such behavior. 687 This interface is also used to instruct an SFC-aware SF about any 688 metadata it needs to attach to packets for a given SFC. This 689 instruction may occur any time during the validity lifetime of an 690 SFC/SFP. 692 Also, this interface informs the SFC-aware SF about the semantics of 693 a context information, which would otherwise have opaque meaning. 694 Several attributes may be associated with a context information such 695 as (but not limited to) the "scope" (e.g., per-packet, per-flow, or 696 per host), whether it is "mandatory" or "optional" to process flows 697 bound to a given chain, etc. Note that a context may be mandatory 698 for "chain 1", but optional for "chain 2". In particular, this 699 interface must provide NSH MD#1 mandatory context semantics, 700 including any suitable scoping information. 702 The control plane may indicate, for a given service function chain, 703 an order for consuming a set of contexts supplied in a packet. This 704 order may be indicated any time during the validity lifetime of an 705 SFC/SFP. 707 An SFC-aware SF can also be instructed about the behavior it should 708 adopt after consuming a context information that was supplied in the 709 SFC header. For example, the context can be maintained, updated, or 710 stripped. 712 Multiple SFs may be located within the same physical node, but no SFF 713 is enabled in that same node, means to unambiguously forward the 714 traffic from the SFF to the appropriate SF must be supported. 715 Concretely, each SF must have a unique locator for unambiguous 716 forwarding. This locator may be configured using this interface. 718 The controller may use the C3 interface to specify how the reverse 719 path of flows, that are processed for a given direction, is selected 720 by the SF. This feature is useful, for example, for packets 721 generated by an SFC-aware SF to ensure these packets are forwarded to 722 the corresponding source node with the same set of SFs, involved in 723 the forward path, are invoked in the reverse order when forwarding 724 back these packets. Special care should be considered to avoid that 725 instructions provided to distinct SFs lead to loops. Additional 726 considerations are discussed in Section 4.2. 728 3.3.4. C4: Interface between SFC Control Plane & SFC Proxy 730 This interface is used by an SFC proxy to report the set of context 731 information (a.k.a., metadata) that it supports and any change of its 732 capabilities that may result, for example, in a software update. 733 Such change notifications should be dynamic, by default. A 734 configuration parameter may be supported to disable such behavior. 736 The SFC proxy can be instructed about authorized SFC-unaware SFs it 737 can service. This instruction may occur during the bootstrapping of 738 the SFC proxy or anytime during the SFP proxy operation time. 740 An SFC proxy may be instructed about the behavior it should adopt to 741 process the context information that was supplied in the SFC header 742 on behalf of an SFC-unaware SF, e.g., the context can be maintained 743 or stripped. 745 The SFC proxy is also instructed about the semantics of a context 746 information (including MD#1), which would otherwise have opaque 747 meaning. Several attributes may be associated with a context 748 information such as (but not limited to) the "scope" (e.g., per- 749 packet, per-flow or per host), whether it is "mandatory" or 750 "optional" to process flows bound to a given chain, etc. 752 The SFC proxy may also be instructed to add some new context 753 information into the SFC header on behalf of an SFC-unaware SF. 755 The C4 interface is also used for collecting attribute states (e.g., 756 availability, workload, latency), for example, to dynamically adjust 757 Service Function Paths. 759 This interface may also be used to instruct the SFC proxy about the 760 state and information to maintain for proper handling of packets 761 received back from an SFC-unaware SF. 763 4. Additional Considerations 765 4.1. Discovery of the SFC Control Element 767 SFC data plane functional elements need to be provisioned with the 768 locators of the Control Elements. This can be achieved using a 769 variety if mechanisms such as static configuration or the activation 770 of a service discovery mechanism. The exact specification of how 771 this provisioning is achieved is out of scope. 773 4.2. SF Symmetry 775 Some SFs require both directions of a flow to traverse. Some service 776 function chains require full symmetry. If an SF (e.g., stateful 777 firewall or NAT) needs both direction of a flow, it is the SF 778 instantiation that needs both direction of a flow to traverse, not 779 the abstract SF (which can have many instantiations spread across the 780 network). 782 Typically: 784 o C1 interface is used to instruct the classifier how both 785 directions of a flow should be processed when crossing an SFC- 786 enabled domain. 788 o C2 interface may be used to ensure that the same SF instance is 789 involved in both directions of a flow (including, to ensure full 790 chain symmetry). 792 4.3. Pre-deploying SFCs 794 Enabling service function chains should preserve some deployment 795 practices adopted by Operators. Particularly, installing a service 796 function chain (and its associated SFPs) should allow for pre- 797 deployment testing and validation purposes (that is a restricted and 798 controlled usage of such service function chain (and associated 799 SFPs)). 801 4.4. Withdraw a Service Function (SF) 803 During the lifetime of an SFC, a given SF can be decommissioned. To 804 accommodate such context and any other case where an SF is to be 805 withdrawn, the control plane should instruct the SFC data plane 806 functional element about the behavior to adopt. For example: 808 1. a first approach would be to update the service function chains 809 and/or associated SFPs where that SF is present by removing any 810 reference to that SF. The update concerns service function 811 chains if the decommissioned SF is not provided by any active 812 node. SFPs are impacted when alternate SF instances can provide 813 the same service of the decommissioned SF instance. 815 2. a second approach would be to delete/deactivate any service 816 function chain (and its associated SFPs) that involves that SF 817 but install new service function chains. 819 4.5. SFC/SFP Operations 821 Various actions can be executed on a service function chain (and 822 associated SFPs) that is structured by the SFC control plane. 823 Indeed, a service function chain (and associated SFPs) can be 824 enabled, disabled, its structure modified by adding a new SF hop or 825 remove an SF from the sequence of SFs to be invoked, its 826 classification rules modified, etc. 828 A modification of a service function chain can trigger control 829 messages with the appropriate SFC-aware nodes accordingly. 831 The approach to be followed to migrate traffic to a new SFP from an 832 old SFP is deployment-specific. For example, in order to avoid 833 service disruption, a make-before-break mechanism can be followed 834 where a new SFP is allocated to replace an existing SFP. Once the 835 new SFP is set up, tested and the traffic is migrated to it, the old 836 SFP can be removed. Other strategies may be followed within an SFC- 837 enabled domain. 839 4.6. Unsolicited (Notification) Messages 841 SFC data plane functional elements must be instructed to send 842 unsolicited notifications when loops are detected, a problem in the 843 structure of a service function chain is encountered, a long 844 unavailable forwarding path time is observed, etc. 846 Specific criteria to send unsolicited notifications to a Control 847 Element should be fine tuned by the control plane using the interface 848 defined in Section 3.3. 850 4.7. Liveness Detection 852 The control plane must allow to detect the liveliness of SFC data 853 plane elements of an SFC-enabled domain. Note that a data element 854 may responsive from a connectivity standpoint, but the service it is 855 supposed to provide may not be available. 857 In particular, the control plane must allow to dynamically detect 858 that an SF instance is out of service and notify the relevant Control 859 Element accordingly. The liveness information may be acquired 860 directly from SFs or indirectly from other management and control 861 systems in the operational environment. 863 Liveness status records for all SF instances, and service function 864 chains (including the SFPs bound to a given chain) are maintained by 865 the SFC Control. 867 The classifier may be notified by the control plane or be part of the 868 liveness detection procedure. 870 The ability of an SFC Control Element to check the liveness of each 871 SF present in service function chain has several advantages, 872 including: 874 o Enhanced status reporting by the control plane (i.e., an 875 operational status for any given service chain derived from 876 liveness state of its SFs). 877 o Ability to support various resiliency policies (i.e., bypass a 878 node embedding an SF, use alternate node, use alternate chain, 879 drop traffic, etc.) . 880 o Ability to support load balancing capabilities to solicit multiple 881 SF instances that provide equivalent functions. 883 Local failure detect and repair mechanisms may be enabled by SFC- 884 aware nodes. Control Elements may be fed directly or indirectly with 885 inputs from these mechanisms. 887 Because a node embedding an SF can be responsive from a reachability 888 standpoint (e.g., IP level) while the function it provides may be 889 broken (e.g., a NAT module may be down), additional means to assess 890 whether an SF is up and running are required. These means may be 891 service-specific. 893 4.8. Monitoring & Counters 895 SFC-specific counters and statistics must be provided using the 896 interfaces defined in Section 3.3. These data include (but not 897 limited to): 899 o Number of flows ever and currently assigned to a given service 900 function chain and a given SFP. 901 o Number of flows, packets, bytes dropped due to policy. 902 o Number of packets and bytes in/out per service function chain and 903 SFP. 904 o Number of flows, packets, bytes dropped due to unknown service 905 function chain (this is valid in particular for an SF node). 907 Even if setting the data collection cycle is deployment-specific, it 908 is recommended to support dynamic means for better SFC automation. 910 4.9. Validity Lifetime 912 SFC instructions communicated via the various interfaces introduced 913 in Section 3.3 may be associated with validity lifetimes, in which 914 case classification and SFP Forwarding Policy Table entries will be 915 automatically removed upon the expiry of the validity lifetime 916 without requiring an explicit action from a Control Element. 918 Lifetimes are used in particular by an SFC data plane element to 919 clear invalid control entries that would be maintained in the system 920 if, for some reason, no appropriate action was undertaken by the 921 control plane to clear such entries. 923 Both short and long lifetimes may be assigned. 925 4.10. Considerations Specific to the Centralized Path Computation Model 927 This section focuses on issues that are specific to the centralized 928 deployment model (Section 3.2). 930 4.10.1. Service Function Path Adjustment 932 An SFP is determined by composing SF instances and overlay links 933 among SFFs. Thus, the status of an SFP depends on the states or 934 attributes (e.g., availability, topological location, latency, 935 workload, etc.) of its components. For example, failure of a single 936 SF instance results in failure of the whole SFP. Since these states 937 or attributes of SFP components may vary in time, their changes 938 should monitored and SFPs should be dynamically adjusted. 940 Examples of use cases for SFP adjustment are listed below: 942 SFP fail-over: re-construct an SFP with replacing the failed SF 943 instance with another instance of the same SF or withdraw the 944 failed SF from being invoked. Note that withdrawing an SF may be 945 envisaged if the resulting connectivity service is not broken 946 (that is, packets bound to the updated SFP can be successfully 947 delivered to their ultimate destinations). Rerouting the traffic 948 to another SF instance or withdrawing the failed SF is deployment- 949 specific. 951 SFP with better latency experience: re-construct an SFP with a low 952 path stretch considering the changes in topological locations of 953 SF instances and the latency induced by the (overlay) connectivity 954 among SFFs. 956 Traffic engineered SFP: re-construct SFPs to localize the traffic in 957 the network considering various TE goals such as bypass a node, 958 bypass a link, etc. These techniques may be used for planned 959 maintenance operations on an SFC-enabled domain. 961 SF/SFP Load-balancing: re-construct SFPs to distribute the workload 962 among various SF instances. Particularly, load distribution 963 policies can be taken into account by the Control Element to re- 964 compute an SFP or be provisioned as attributes to SFPs that will 965 be installed using the control interfaces (C2 interface, 966 typically). 968 For more details about the use cases, refer to 969 [I-D.lee-nfvrg-resource-management-service-chain]. 971 The procedures for SFP adjustment may be handled by the SFC control 972 plane as follows: 974 o Collect and monitor states and attributes of SF instances and 975 overlay links via the C2 interface (Section 3.3.2) and the C3 976 interface (Section 3.3.3). 978 o Evaluate SF instances and overlay links based on the monitoring 979 results. 981 o Select SF instances to re-determine an SFP according to the 982 evaluation results. 984 o Replace target SF instances (e.g., in a failure or overladed) with 985 newly selected ones. 987 o Enforce the updated SFP for upcoming SFC traversal to SFFs via the 988 C1 interface (Section 3.3.1) or the C2 interface (Section 3.3.2). 990 4.10.2. Head End Initiated SFP Establishment 992 In some scenarios where an SFC Control Element is not connected to 993 all SFFs in an SFC-enabled domain, the SFC control plane can send the 994 explicit SFF/SF sequence or SF sequence to the SFC head-end, e.g., 995 the classifier via the C1 interface (Section 3.3.1). SFC head-end 996 can use a signaling protocol to establish the SFF/SF sequence based 997 on the SF sequence. Additional information (e.g., SF/SFF load) may 998 be communicated to the SFC head-end to adjust an SFP. 1000 4.10.3. (Regional) Restoration of Service Functions 1002 There are situations that it might not be feasible for the classifier 1003 to be notified of the changes of SFF-sequence or SFF/SF Sequence for 1004 a given SFP because of the time taken for the notification and the 1005 limited capability of the classifiers. 1007 If an SF has a large number of instantiations, it scales better if 1008 the classifier doesn't need to be notified with status of visible 1009 instantiations of SFs on an SFP. 1011 It might not be always feasible for the classifier to be aware of the 1012 exact SF instances selected for a given SFP due to too many instances 1013 for each SF, notifications not being promptly sent to the classifier, 1014 or other reasons. This is about multiple instances of the same SF 1015 attached to one SFF node; those instances can be handled by the SFF 1016 via local load balancing schemes. 1018 Regional restoration can take the similar approach as the global 1019 restoration: choosing a regional ingress node that can take over the 1020 responsibility of installing the new steering policies to the 1021 involved SFFs or network nodes. Typically, the regional ingress node 1022 should be: 1024 o on the data path of the flow of the given SFC; 1025 o in front of the relevant SFFs or network nodes that are impacted 1026 by the change of the SFP; 1027 o capable of encoding the detailed SFP to the Service Chain Header 1028 of data packets of the identified flow; and 1029 o capable of removing the detailed SFP encoding in data packets 1030 after all the impacted SFFs and network nodes completed the policy 1031 installation. 1033 4.10.4. Fully Controlled SFF/SF Sequence for a SFP 1035 This section discusses some information that can be exchanged over C2 1036 interface (Section 3.3.2) when the SFC Control Element explicitly 1037 passes the steering policies to all SFFs for the SFF/SF sequence of a 1038 given SFC. In this model, each SFF doesn't need to signal other SFFs 1039 for the SFP. 1041 The SFF nodes are not required to be directly adjacent to each other. 1042 As such, they can be interconnected using an overlay technique, such 1043 as Generic Routing Encapsulation (GRE), Virtual eXtensible Local Area 1044 Network (VXLAN), etc. SFs are attached to an SFF node or SFC proxy 1045 node via Ethernet link or other link types. As a local decision, 1046 there may be multiple different steering policies that work in 1047 conjunction with the SFC encapsulation [I-D.ietf-sfc-nsh] for one 1048 flow within one SFF. 1050 For example, the semantics of traffic steering rules can be a match 1051 condition and an action, similar to, e.g., the route described in 1052 Section 2.3 of [I-D.ietf-i2rs-rib-info-model]. The match conditions 1053 and action for distinct ports can be different. 1055 The matching criteria for SFF can be more sophisticated. For 1056 example, it could be the SFP-id carried within the SFC encapsulation 1057 with any fields in the data packets, such as (non-exhaustive list): 1059 o Destination MAC address 1060 o Source MAC address 1061 o VLAN-ID, 1062 o Destination IP address 1063 o Source IP address 1064 o Source port number 1065 o Destination port number 1066 o Differentiated Services Code Point (DSCP) 1067 o Packet size, etc., or any combination thereof. 1069 An SFF node may not support some of the matching criteria listed 1070 above. It is important that SFC control plane can retrieve the 1071 supported matching criteria by SFF nodes. The actions for traffic 1072 steering could be to steer traffic to the attached SF instances via a 1073 specific port. 1075 The actions to SFC proxy may include a method to map the SFP 1076 identifier carried in the packet header to a locally significant link 1077 identifier, e.g., VLAN-ID, and a method to construct and encapsulate 1078 the SFC header back to the packets when they come back from the 1079 attached SFs. 1081 This approach does not require using an end-to-end signaling protocol 1082 among classifier nodes and SFF nodes. However, there may be problems 1083 encountered if SFF nodes are not updated in the proper order or not 1084 at the same time. For example, if the SFF "A" and SFF "C" get flow 1085 steering policies at slightly different times, some packets might not 1086 be directed to some service functions on a chain. 1088 5. Security Considerations 1090 5.1. Secure Communications 1092 The SFC Control Elements and the participating SFC data plane 1093 elements must mutually authenticate. SFC data plane elements must 1094 ignore instructions received from unauthenticated SFC Control 1095 Elements. The credentials details used during authentication can be 1096 used by the SFC control plane to decide whether specific 1097 authorization may be granted to a Service Function with regards to 1098 some specific operations (e.g., authorize a given SF to access 1099 specific context information). 1101 In case multiple SFC data plane elements are embedded in the same 1102 node, the authentication mechanism may be executed as a whole; not 1103 for each instance. 1105 An SFC data plane element must be able to send authenticated 1106 unsolicited notifications to an SFC Control Element. 1108 The communication between a Control Element and SFC data plane 1109 elements must provide integrity and replay protection. 1111 A Service Function must by default discard any action from an SFC 1112 Control Element that requires specific right privileges (e.g., access 1113 to a legal intercept log, mirror the traffic, etc.). 1115 5.2. Pervasive Monitoring 1117 The authentication mechanism should be immune to pervasive monitoring 1118 [RFC7258]. An attacker can intercept traffic by installing 1119 classification rules that would lead to redirect all or part of the 1120 traffic to an illegitimate network node. Means to protect against 1121 attacks that would lead to install, remove, or modify classification 1122 rules must be supported. 1124 5.3. Privacy 1126 The SFC control plane must be able to instruct SFC data plane 1127 elements about the information to be leaked outside an SFC-enabled 1128 domain. Particularly, the SFC control plane must support means to 1129 preserve privacy [RFC6973]. Context headers may indeed reveal 1130 privacy information (e.g., IMSI, user name, user profile, location, 1131 etc.). Those headers must not be exposed outside the operator's 1132 domain. 1134 5.4. Denial-of-Service (DoS) 1136 In order to protect against denial of service that would be caused by 1137 a misbehaving trusted SFC Control Element, SFC data plane elements 1138 should rate limit the messages received from an SFC Control Element. 1140 5.5. Illegitimate Discovery of SFs and SFC Control Elements 1142 Means to defend against soliciting illegitimate SFs/SFFs that do not 1143 belong to the SFC-enabled domain must be enabled. Such means must be 1144 defined in service function discovery and SFC Control Element 1145 discovery specification documents. 1147 6. IANA Considerations 1149 This document does not require any IANA actions. 1151 7. Acknowledgments 1153 This document is the result of merging with 1154 [I-D.lee-sfc-dynamic-instantiation]. 1156 Hongyu Li, Qin Wu, and Yong(Oliver) Huang edited an early version of 1157 the individual submission of this document. 1159 Many thanks to Shibi Huang, Lac Chidung, Taeho Kang, Sumandra Majee, 1160 Dave Dolson, Paul Bottorff, Reinaldo Penno, Jim Guichard, Shunsuke 1161 Homma, Ken Gray, Henry Fourie, and Dirk von Hugo for the feedback and 1162 discussion on the mailing list. 1164 The text about the semantic of a context information is provided by 1165 Dave Dolson and Lucy Yong. 1167 Many thanks to Paul Quinn and Uri Elzur for the detailed review. 1169 Thanks to Catherine Meadows for the SecDir review, and to Stephen 1170 Farrell and Tero Kivinen for scheduling an early SecDir review. 1172 Special thanks to Alia Atlas for the careful AD review. 1174 8. Contributors 1176 The following individuals have contributed significantly to this 1177 document: 1179 Hongyu Li 1180 Huawei 1181 Huawei Industrial Base,Bantian,Longgang 1182 Shenzhen 1183 China 1185 EMail: hongyu.li@huawei.com 1187 Qin Wu 1188 Huawei 1189 101 Software Avenue, Yuhua District 1190 Nanjing, Jiangsu 210012 1191 China 1193 EMail: bill.wu@huawei.com 1195 Yong(Oliver) Huang 1196 Huawei 1197 Huawei Industrial Base,Bantian,Longgang 1198 Shenzhen 1199 China 1201 EMail: oliver.huang@huawei.com 1202 Christian Jacquenet 1203 Orange 1204 Rennes 35000 1205 France 1207 EMail: christian.jacquenet@orange.com 1209 Walter Haeffner 1210 Vodafone D2 GmbH 1211 Ferdinand-Braun-Platz 1 1212 Duesseldorf 40549 1213 DE 1215 EMail: walter.haeffner@vodafone.com 1217 Seungik Lee 1218 ETRI 1219 218 Gajeong-ro Yuseung-Gu 1220 Daejeon 305-700 1221 Korea 1223 Phone: +82 42 860 1483 1224 EMail: seungiklee@etri.re.kr 1226 Ron Parker 1227 Affirmed Networks 1228 Acton 1229 MA 01720 1230 USA 1232 EMail: ron_parker@affirmednetworks.com 1234 Linda Dunbar 1235 Huawei Technologies 1236 USA 1238 EMail: ldunbar@huawei.com 1240 Andrew Malis 1241 Huawei Technologies 1242 USA 1244 EMail: agmalis@gmail.com 1245 Joel M. Halpern 1246 Ericsson 1248 EMail: joel.halpern@ericsson.com 1250 Tirumaleswar Reddy 1251 Cisco Systems, Inc. 1252 Cessna Business Park, Varthur Hobli 1253 Sarjapur Marathalli Outer Ring Road 1254 Bangalore, Karnataka 560103 1255 India 1257 EMail: tireddy@cisco.com 1259 Prashanth Patil 1260 Cisco Systems, Inc. 1261 Bangalore 1262 India 1264 EMail: praspati@cisco.com 1266 9. References 1268 9.1. Normative References 1270 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1271 Chaining (SFC) Architecture", RFC 7665, 1272 DOI 10.17487/RFC7665, October 2015, 1273 . 1275 9.2. Informative References 1277 [I-D.ietf-i2rs-rib-info-model] 1278 Bahadur, N., Kini, S., and J. Medved, "Routing Information 1279 Base Info Model", draft-ietf-i2rs-rib-info-model-09 (work 1280 in progress), July 2016. 1282 [I-D.ietf-opsawg-firewalls] 1283 Baker, F. and P. Hoffman, "On Firewalls in Internet 1284 Security", draft-ietf-opsawg-firewalls-01 (work in 1285 progress), October 2012. 1287 [I-D.ietf-sfc-dc-use-cases] 1288 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 1289 Homma, "Service Function Chaining Use Cases In Data 1290 Centers", draft-ietf-sfc-dc-use-cases-05 (work in 1291 progress), August 2016. 1293 [I-D.ietf-sfc-nsh] 1294 Quinn, P. and U. Elzur, "Network Service Header", draft- 1295 ietf-sfc-nsh-10 (work in progress), September 2016. 1297 [I-D.ietf-sfc-use-case-mobility] 1298 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 1299 J. Uttaro, "Service Function Chaining Use Cases in Mobile 1300 Networks", draft-ietf-sfc-use-case-mobility-07 (work in 1301 progress), October 2016. 1303 [I-D.lee-nfvrg-resource-management-service-chain] 1304 Lee, S., Pack, S., Shin, M., and E. Paik, "Resource 1305 Management in Service Chaining", draft-lee-nfvrg-resource- 1306 management-service-chain-01 (work in progress), March 1307 2015. 1309 [I-D.lee-sfc-dynamic-instantiation] 1310 Lee, S., Pack, S., Shin, M., and E. Paik, "SFC dynamic 1311 instantiation", draft-lee-sfc-dynamic-instantiation-01 1312 (work in progress), October 2014. 1314 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1315 Address Translator (Traditional NAT)", RFC 3022, 1316 DOI 10.17487/RFC3022, January 2001, 1317 . 1319 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1320 Shelby, "Performance Enhancing Proxies Intended to 1321 Mitigate Link-Related Degradations", RFC 3135, 1322 DOI 10.17487/RFC3135, June 2001, 1323 . 1325 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1326 NAT64: Network Address and Protocol Translation from IPv6 1327 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1328 April 2011, . 1330 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1331 Stack Lite Broadband Deployments Following IPv4 1332 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1333 . 1335 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1336 Morris, J., Hansen, M., and R. Smith, "Privacy 1337 Considerations for Internet Protocols", RFC 6973, 1338 DOI 10.17487/RFC6973, July 2013, 1339 . 1341 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1342 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1343 2014, . 1345 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1346 Service Function Chaining", RFC 7498, 1347 DOI 10.17487/RFC7498, April 2015, 1348 . 1350 Author's Address 1352 Mohamed Boucadair (editor) 1353 Orange 1354 Rennes 1355 35000 1356 France 1358 EMail: mohamed.boucadair@orange.com