idnits 2.17.1 draft-ietf-sfc-oam-framework-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2019) is 1766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8029' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 876, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-sfc-proof-of-transit-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Aldrin 3 Internet-Draft Google 4 Intended status: Informational C. Pignataro, Ed. 5 Expires: December 27, 2019 N. Kumar, Ed. 6 Cisco 7 R. Krishnan 8 VMware 9 A. Ghanwani 10 Dell 11 June 25, 2019 13 Service Function Chaining (SFC) 14 Operations, Administration and Maintenance (OAM) Framework 15 draft-ietf-sfc-oam-framework-08 17 Abstract 19 This document provides a reference framework for Operations, 20 Administration and Maintenance (OAM) for Service Function Chaining 21 (SFC). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in RFC 28 2119 [RFC2119] RFC 8174 [RFC8174] when and only when, they appear in 29 all capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 27, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 4 67 1.2. Acronyms and Terminology . . . . . . . . . . . . . . . . 4 68 1.2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2.2. Terminology . . . . . . . . . . . . . . . . . . . . . 4 70 2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 4 71 3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. The SF Component . . . . . . . . . . . . . . . . . . . . 7 73 3.1.1. SF Availability . . . . . . . . . . . . . . . . . . . 7 74 3.1.2. SF Performance Measurement . . . . . . . . . . . . . 8 75 3.2. The SFC Component . . . . . . . . . . . . . . . . . . . . 8 76 3.2.1. SFC Availability . . . . . . . . . . . . . . . . . . 8 77 3.2.2. SFC Performance Measurement . . . . . . . . . . . . . 9 78 3.3. The Classifier Component . . . . . . . . . . . . . . . . 9 79 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 10 81 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 10 82 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 10 83 4.4. Performance Management Functions . . . . . . . . . . . . 11 84 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 12 85 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 12 86 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 13 87 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 13 88 6. Candidate SFC OAM Tools . . . . . . . . . . . . . . . . . . . 13 89 6.1. SFC OAM Packet Marker . . . . . . . . . . . . . . . . . . 13 90 6.2. OAM Packet Processing and Forwarding Semantic . . . . . . 14 91 6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 14 92 6.4. OAM Toolset Applicability . . . . . . . . . . . . . . . . 15 93 6.4.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . 15 94 6.4.2. BFD/Seamless-BFD . . . . . . . . . . . . . . . . . . 15 95 6.4.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . 16 96 6.4.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . 16 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 100 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 103 11.2. Informative References . . . . . . . . . . . . . . . . . 18 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 106 1. Introduction 108 Service Function Chaining (SFC) enables the creation of composite 109 services that consist of an ordered set of Service Functions (SF) 110 that are to be applied to packets and/or frames selected as a result 111 of classification [RFC7665]. SFC is a concept that provides for more 112 than just the application of an ordered set of SFs to selected 113 traffic; rather, it describes a method for deploying SFs in a way 114 that enables dynamic ordering and topological independence of those 115 SFs as well as the exchange of metadata between participating 116 entities. The foundations of SFC are described in the following 117 documents: 119 o SFC Problem Statement [RFC7498] 121 o SFC Architecture [RFC7665] 123 The reader is assumed to be familiar with the material in these 124 documents. 126 This document provides a reference framework for Operations, 127 Administration and Maintenance (OAM, [RFC6291]) of SFC. 128 Specifically, this document provides: 130 o In Section 2, an SFC layering model; 132 o In Section 3, aspects monitored by SFC OAM; 134 o In Section 4, functional requirements for SFC OAM; 136 o In Section 5, a gap analysis for SFC OAM. 138 SFC OAM solution documents should refer to this document to indicate 139 the SFC OAM component and the functionality they target. 141 OAM controllers are assumed to be within the same administrative 142 domain as the target SFC enabled domain. 144 1.1. Document Scope 146 The focus of this document is to provide an architectural framework 147 for SFC OAM, particularly focused on the aspect of the Operations 148 component within OAM. Actual solutions and mechanisms are outside 149 the scope of this document. 151 1.2. Acronyms and Terminology 153 1.2.1. Acronyms 155 SFC: Service Function Chain 157 SFF: Service Function Forwarder 159 SF: Service Function 161 SFP: Service Function Path 163 RSP: Rendered Service Path 165 NSH: Network Service Header 167 VM: Virtual Machines 169 OAM: Operations, Administration and Maintenance 171 IPPM: IP Performance Metrics 173 BFD: Bidirectional Forwarding Detection 175 NVo3: Network Virtualization over Layer3 177 SNMP: Simple Network Management Protocol 179 NETCONF: Network Configuration Protocol 181 1.2.2. Terminology 183 This document uses the terminologies defined in [RFC7665], [RFC8300], 184 and so the readers are expected to be familiar with the same. 186 2. SFC Layering Model 188 Multiple layers come into play for implementing the SFC. These 189 include the service layer and the underlying layers (Network Layer, 190 Link Layer, etc.). 192 o The service layer, which consists of SFC data plane elements that 193 includes classifiers, Service Functions (SF), Service Function 194 Forwarders (SFF), and SFC Proxies. This layer uses the overlay 195 network for ensuring connectivity between SFC data plane elements. 197 o The overlay network layer, which leverages various overlay network 198 technologies interconnecting SFC data plane elements and allows 199 establishing Service Function Paths (SFPs). This layer is mostly 200 transparent to the SFC data plane elements. 202 o The underlay network layer, which is dictated by the networking 203 technology deployed within a network (e.g., IP, MPLS) 205 o The link layer, which is dependent upon the physical technology 206 used. Ethernet is a popular choice for this layer, but other 207 alternatives are deployed (e.g. POS, DWDM). The same or distinct 208 link layer technologies may be used in each leg shown in Figure 1. 210 o----------------------Service Layer----------------------o 212 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 213 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 214 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 215 +------+ 216 <------VM1------> <--VM2--> <--VM3--> 218 ^-----------------^-------------------^---------------^ Overlay network 220 o-----------------o-------------------o---------------o Underlay network 222 o--------o--------o--------o--------o--------o--------o Link 224 Figure 1: SFC Layering Example 226 In Figure 1, the service layer element such as classifier and SF are 227 depicted as virtual machines that are interconnected using an overlay 228 network. The underlay network may comprise of multiple intermediate 229 nodes but not shown in the figure that provides underlay connectivity 230 between the service layer elements. 232 While Figure 1 depicts a sample example where SFs are enabled as 233 virtual entities, the SFC architecture does not make any assumptions 234 on how the SFC data plane elements are deployed. The SFC 235 architecture is flexible and accommodates physical or virtual entity 236 deployment. SFC OAM accounts for this flexibility and accordingly it 237 is applicable whether SFC data plane elements are deployed directly 238 on physical hardware, as one or more Virtual Machines, or any 239 combination thereof. 241 3. SFC OAM Components 243 The SFC operates at the service layer. For the purpose of defining 244 the OAM framework, the service layer is broken up into three distinct 245 components: 247 1. SF component: OAM functions applicable at this component includes 248 testing the SFs from any SFC-aware network devices (e.g., 249 classifiers, controllers, other service nodes). Testing an SF 250 may not be restricted to connectivity to the SF, but also whether 251 the SF is providing its intended service. Refer to Section 3.1.1 252 for a more detailed discussion. 254 2. SFC component: OAM functions applicable at this component 255 includes (but are not limited to) testing the service function 256 chains and the SFPs, validaion of the correlation between an SFC 257 and the actual forwarding path followed by a packet matching that 258 SFC, i.e. the Rendered Service Path (RSP). Some of the hops of 259 an SFC may not be visible when Hierarchical Service Function 260 Chaining (hSFC) [RFC8459] is in use. In such schemes, it is the 261 responsibility of the Internal Boundary Node (IBN) to glue the 262 connectivity between different levels for end-to-end OAM 263 functionality. 265 3. Classifier component: OAM functions applicable at this component 266 includes testing the validity of the classification rules and 267 detecting any incoherence among the rules installed in different 268 classifiers. 270 Figure 2 illustrates an example where OAM for the three defined 271 components are used within the SFC environment. 273 +-Classifier +-Service Function Chain OAM 274 | OAM | 275 | | ______________________________________________ 276 | \ /\ Service Function Chain \ 277 | \ / \ +---+ +---+ +-----+ +---+ \ 278 | \ / \ |SF1| |SF2| |Proxy|--|SF3| \ 279 | +------+ \/ \ +---+ +---+ +-----+ +---+ \ 280 +----> | |....(+-> ) | | | ) 281 |Classi| \ / +-----+ +-----+ +-----+ / 282 |fier | \ / | SFF1|----| SFF2|----| SFF3| / 283 | | \ / +--^--+ +--^--+ +-----+ / 284 +----|-+ \/____________|________________________________/ 285 | | 286 +----------SF_OAM-------+ 287 +---+ +---+ 288 +SF_OAM>|SF3| |SF5| 289 | +-^-+ +-^-+ 290 +------|---+ | | 291 |Controller| +-SF_OAM+ 292 +----------+ 293 Service Function OAM (SF_OAM) 295 Figure 2: SFC OAM Components 297 It is expected that multiple SFC OAM solutions will be defined, each 298 targeting one specific component of the service layer. However, it 299 is critical that SFC OAM solutions together provide the coverage of 300 all three SFC OAM components: the SF component, the SFC component, 301 and the classifier component. 303 3.1. The SF Component 305 3.1.1. SF Availability 307 One SFC OAM requirement for the SF component is to allow an SFC-aware 308 network device to check the availability of a specific SF (instance), 309 located on the same or different network device(s). The SF 310 availability may be performed to check the availability of any 311 instance of a specific SFn or it can be a specific instance of a SF. 312 SF availability is an aspect that raises an interesting question -- 313 How to determine that a service function is available?. On one end 314 of the spectrum, one might argue that an SF is sufficiently available 315 if the service node (physical or virtual) hosting the SF is available 316 and is functional. On the other end of the spectrum, one might argue 317 that the SF's availability can only be concluded if the packet, after 318 passing through the SF, was examined and it was verified that the 319 packet did indeed get the got expected service. 321 The former approach will likely not provide sufficient confidence to 322 the actual SF availability, i.e. a service node and a SF are two 323 different entities. The latter approach is capable of providing an 324 extensive verification, but comes at a cost. Some SFs make direct 325 modifications to packets, while others do not. Additionally, the 326 purpose of some SFs may be to, conditionally, drop packets 327 intentionally. In such cases, it is normal behavior that certain 328 packets will not be egressing out from the service function. The OAM 329 mechanism needs to take into account such SF specifics when assessing 330 SF availability. Note that there are many flavors of SFs available, 331 and many more that are likely be introduced in future. Even a given 332 SF may introduce a new functionality (e.g., a new signature in a 333 firewall). The cost of this approach is that the OAM mechanism for 334 some SF will need to be continuously modified in order to "keep up" 335 with new functionality being introduced: lack of extendibility. 337 This framework document provides a RECOMMENDED framework where a 338 generalized approach is taken to verify that a SF is sufficiently 339 available (i.e., an adequate granularity to provide a basic SF 340 service). More specifics on the mechanism to characterize SF- 341 specific OAM to validate the service offering are outside the scope 342 of this document. Those fine-grained mechanisms are implementation- 343 and deployment-specific. 345 3.1.2. SF Performance Measurement 347 The second SFC OAM requirement for the SF component is to allow an 348 SFC-aware network device to check the performance metrics such as 349 loss and delay induced by a specific SF for processing legitimate 350 traffic. The performance can be a passive measurement by using live 351 traffic or can be active measurement by using synthetic probe 352 packets. 354 On the one hand, the performance of any specific SF can be quantified 355 by measuring the loss and delay metrics of the traffic from SFF to 356 the respective SF, while on the other hand, the performance can be 357 measured by leveraging the loss and delay metrics from the respective 358 SFs. The latter requires SF involvement to perform the measurement 359 while the former does not. 361 3.2. The SFC Component 363 3.2.1. SFC Availability 365 An SFC could be comprised of varying SFs and so the OAM layer is 366 required to perform validation and verification of SFs within an SFP, 367 in addition to connectivity verification and fault isolation. 369 In order to perform service connectivity verification of an SFC/SFP, 370 the OAM functions could be initiated from any SFC-aware network 371 devices of an SFC-enabled domain for end-to-end paths, or partial 372 paths terminating on a specific SF, within the SFC/SFP. The goal of 373 this OAM function is to ensure the SFs chained together have 374 connectivity as was intended at the time when the SFC was 375 established. The necessary return codes should be defined for 376 sending back in the response to the OAM packet, in order to complete 377 the verification. 379 When ECMP is in use at the service layer for any given SFC, there 380 MUST be the ability to discover and traverse all available paths. 382 A detailed explanation of the mechanism is outside the scope of this 383 document and is expected to be included in the actual solution 384 document. 386 3.2.2. SFC Performance Measurement 388 Any SFC-aware network device SHOULD have the ability to make 389 performance measurements over the entire SFC (i.e., end-to-end) or to 390 a specific segment of SFs within the SFC. 392 3.3. The Classifier Component 394 A classifier maintains the classification rules that map a flow to a 395 specific SFC. It is vital that the classifier is correctly 396 configured with updated classification rules and is functioning as 397 expected. The SFC OAM must be able to validate the classification 398 rules by assessing whether a flow is appropriately mapped to the 399 relevant SFC. Sample OAM packets can be presented to the classifiers 400 to assess the behavior with regard to a given classification entry. 402 4. SFC OAM Functions 404 Section 3 described SFC OAM operations that are required on each SFC 405 component. This section explores SFC OAM functions that are 406 applicable for more than one SFC components. 408 The various SFC OAM requirements listed in Section 3 highlighted the 409 need for various OAM functions at different layers. As listed in 410 Section 5.1, various OAM functions are in existence that are defined 411 to perform OAM functionality at different layers. In order to apply 412 such OAM functions at the service layer, they need to be enhanced to 413 operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in 414 multiple SFCs. 416 4.1. Connectivity Functions 418 Connectivity is mainly an on-demand function to verify that the 419 connectivity exists between certain network elements and that the SFs 420 are available. For example, LSP Ping is a common tool used to 421 perform this function for an MPLS underlay network. OAM messages 422 SHOULD be encapsulated with necessary SFC header and with OAM 423 markings when testing the SFC component. OAM messages MAY be 424 encapsulated with the necessary SFC header and with OAM markings when 425 testing the SF component. Some of the OAM functions performed by 426 connectivity functions are as follows: 428 o Verify the Path MTU from a source to the destination SF or through 429 the SFC. This requires the ability for the OAM packet to be of 430 variable length packet size. 432 o Verify any packet re-ordering and corruption. 434 o Verify the policy of an SFC or SF. 436 o Verification and validation of forwarding paths. 438 o Proactively test alternate or protected paths to ensure 439 reliability of network configurations. 441 4.2. Continuity Functions 443 Continuity is a model where OAM messages are sent periodically to 444 validate or verify the reachability to a given SF within an SFC or 445 for the entire SFC. This allows a monitoring network device (such as 446 the classifier or controller) to quickly detect failures such as link 447 failures, network element failures, SF outages, or SFC outages. BFD 448 [RFC5880] is one such function which helps in detecting failures 449 quickly. OAM functions supported by continuity function are as 450 follows: 452 o Ability to provision continuity check to a given SF within an SFC 453 or for the entire SFC. 455 o Notifying the detected failures to other OAM functions or 456 applications to take appropriate action. 458 4.3. Trace Functions 460 Tracing is an OAM function that allows the operation to trigger an 461 action (e.g. response generation) from every transit device (e.g. 462 SFF, SF, SFC Proxy) on the tested layer. This function is typically 463 useful for gathering information from every transit devices or for 464 isolating the failure point to a specific SF within an SFC or for an 465 entire SFC. Some of the OAM functions supported by trace functions 466 are: 468 o Ability to trigger action from every transit device at the SFC 469 layer, using TTL or other means. 471 o Ability to trigger every transit device at the SFC layer to 472 generate a response with OAM code(s), using TTL or other means. 474 o Ability to discover and traverse ECMP paths within an SFC. 476 o Ability to skip SFs that do not support OAM while tracing SFs in 477 an SFC. 479 4.4. Performance Management Functions 481 Performance management functions involve measuring of packet loss, 482 delay, delay variance, etc. These performance metrics may be 483 measured pro-actively or on-demand. 485 SFC OAM should provide the ability to measure packet loss for an SFC. 486 On-demand measurement can be used to estimate packet loss using 487 statistical methods. Measuring the loss of OAM packets, an 488 approximation of packet loss for a given SFC can be derived. 490 Delay within an SFC could be measured based on the time it takes for 491 a packet to traverse the SFC from the ingress SFC node to the egress 492 SFF. As SFCs are unidirectional in nature, measurement of one-way 493 delay [RFC7679] is important. In order to measure one-way delay, 494 time synchronization MUST be supported by means such as NTP, PTP, 495 GPS, etc. 497 One-way delay variation [RFC3393] could also be calculated by sending 498 OAM packets and measuring the jitter between the packets passing 499 through an SFC. 501 Some of the OAM functions supported by the performance measurement 502 functions are: 504 o Ability to measure the packet processing delay induced by a single 505 SF or the one-way delay to traverse an SFP bound to a given SFC. 507 o Ability to measure the packet loss [RFC7680] within an SF or an 508 SFP bound to a given SFC. 510 5. Gap Analysis 512 This section identifies various OAM functions available at different 513 levels introduced in Section 2. It also identifies various gaps that 514 exist within the current toolset for performing OAM functions 515 required for SFC. 517 5.1. Existing OAM Functions 519 There are various OAM tool sets available to perform OAM functions 520 within various layers. These OAM functions may be used to validate 521 some of the underlay and overlay networks. Tools like ping and trace 522 are in existence to perform connectivity check and tracing of 523 intermediate hops in a network. These tools support different 524 network types like IP, MPLS, TRILL, etc. There is also an effort to 525 extend the tool set to provide connectivity and continuity checks 526 within overlay networks. BFD is another tool which helps in 527 detecting data forwarding failures. The orchestration tool may be 528 used for network and service orchestration function. Tables 3 and 4 529 are not exhaustive. 531 Table 3: OAM Tool GAP Analysis 532 +----------------+--------------+-------------+--------+------------+ 533 | Layer | Connectivity | Continuity | Trace | Performance| 534 +----------------+--------------+-------------+--------+------------+ 535 | Underlay N/w | Ping | E-OAM, BFD | Trace | IPPM, | 536 | | | | | MPLS_PM | 537 +----------------+--------------+-------------+--------+------------+ 538 | Overlay N/w | Ping |BFD, NVo3 OAM| Trace | IPPM | 539 +----------------+--------------+-------------+--------+------------+ 540 | SF | None + None + None + None | 541 +----------------+--------------+-------------+--------+------------+ 542 | SFC | None + None + None + None | 543 +----------------+--------------+-------------+--------+------------+ 544 Table 4: OAM Tool GAP Analysis (contd.) 545 +----------------+--------------+-------------+--------+-------------+ 546 | Layer |Configuration |Orchestration|Topology|Notification | 547 +----------------+--------------+-------------+--------+-------------+ 548 | Underlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog,| 549 | | | | |NETCONF | 550 +----------------+--------------+-------------+--------+-------------+ 551 | Overlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog | 552 | | | | |NETCONF | 553 +----------------+--------------+-------------+--------+-------------+ 554 | SF |CLI, NETCONF + CLI, NETCONF| None | None | 555 +----------------+--------------+-------------+--------+-------------+ 556 | SFC |CLI, NETCONF + CLI, NETCONF| None | None | 557 +----------------+--------------+-------------+--------+-------------+ 559 5.2. Missing OAM Functions 561 As shown in Table 3, there are no standards-based tools available for 562 the verification of SFs and SFCs. 564 5.3. Required OAM Functions 566 Primary OAM functions exist for underlying layers. Tools like ping, 567 trace, BFD, etc. exist in order to perform these OAM functions. 569 Configuration, orchestration and manageability of SF and SFC could be 570 performed using CLI, NETCONF, etc. 572 As depicted in Tables 3 and 4, information and data models are needed 573 for configuration, manageability and orchestration for SFC. With 574 virtualized SF and SFC, manageability needs to be done 575 programmatically. 577 6. Candidate SFC OAM Tools 579 This section describes the operational aspects of SFC OAM at the 580 service layer to perform the SFC OAM function defined in Section 4 581 and analyzes the applicability of various existing OAM toolsets in 582 the service layer. 584 6.1. SFC OAM Packet Marker 586 The SFC OAM function described in Section 4 performed at the service 587 layer or overlay network layer must mark the packet as an OAM packet 588 so that relevant nodes can differentiate an OAM packet from data 589 packets. The base header defined in Section 2.2 of [RFC8300] assigns 590 a bit to indicate OAM packets. When NSH encapsulation is used at the 591 service layer, the O bit must be set to differentiate the OAM packet. 592 Any other overlay encapsulations used in future must have a way to 593 mark the packet as OAM packet. 595 6.2. OAM Packet Processing and Forwarding Semantic 597 Upon receiving an OAM packet, SFC-aware SFs may choose to discard the 598 packet if it does not support OAM functionality or if the local 599 policy prevents them from processing the OAM packet. When an SF 600 supports OAM functionality, it is desirable to process the packet and 601 provide an appropriate response to allow end-to-end verification. To 602 limit performance impact due to OAM, SFC-aware SFs should rate limit 603 the number of OAM packets processed. 605 An SFF may choose not to forward the OAM packet to an SF if the SF 606 does not support OAM or if the policy does not allow to forward OAM 607 packet to an SF. The SFF may choose to skip the SF, modify the 608 header and forward to next SFC node in the chain. It should be noted 609 that skipping an SF might have implication on some OAM functions 610 (e.g. the delay measurement may not be accurate). The method by 611 which an SFF detects if the connected SF supports or is allowed to 612 process OAM packets is outside the scope of this document. It could 613 be a configuration parameter instructed by the controller or it can 614 be done by dynamic negotiation between the SF and SFF. 616 If the SFF receiving the OAM packet bound to a given SFC is the last 617 SFF in the chain, it must send a relevant response to the initiator 618 of the OAM packet. Depending on the type of OAM solution and tool 619 set used, the response could be a simple response (such as ICMP 620 reply) or could include additional data from the received OAM packet 621 (like statistical data consolidated along the path). The details are 622 expected to be covered in the solution documents. 624 Any SFC-aware node that initiates an OAM packet must set the OAM 625 marker in the overlay encapsulation. 627 6.3. OAM Function Types 629 As described in Section 4, there are different OAM functions that may 630 require different OAM solutions. While the presence of the OAM 631 marker in the overlay header (e.g., O bit in the NSH header) 632 indicates it as OAM packet, it is not sufficient to indicate what OAM 633 function the packet is intended for. The Next Protocol field in NSH 634 header may be used to indicate what OAM function is intended to or 635 what toolset is used. 637 6.4. OAM Toolset Applicability 639 As described in Section 5.1, there are different tool sets available 640 to perform OAM functions at different layers. This section describes 641 the applicability of some of the available toolsets in the service 642 layer. 644 6.4.1. ICMP 646 [RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 647 network respectively. It explains how ICMP messages can be used to 648 test the network reachability between different end points and 649 perform basic network diagnostics. 651 ICMP could be leveraged for connectivity function (defined in 652 Section 4.1) to verify the availability of SF or SFC. The Initiator 653 can generate an ICMP echo request message and control the service 654 layer encapsulation header to get the response from relevant node. 655 For example, a classifier initiating OAM can generate ICMP echo 656 request message, can set the TTL field in NSH header to 255 to get 657 the response from last SFF and thereby test the SFC availability. 658 Alternately, the initiator can set the TTL to some other value to get 659 the response from a specific SFs and there by test partial SFC 660 availability. Alternately, the initiator could send OAM packets with 661 sequentially incrementing the TTL in the NSH to trace the SFP. 663 It could be observed that ICMP at its current stage may not be able 664 to perform all required SFC OAM functions, but as explained above, it 665 can be used for basic OAM functions. 667 6.4.2. BFD/Seamless-BFD 669 [RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism 670 for fast failure detection. [RFC5881] and [RFC5884] defines the 671 applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] 672 defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. 673 [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. 675 BFD or S-BFD could be leveraged to perform SF or SFC availability. 676 An initiator could generate a BFD control packet and set the "Your 677 Discriminator" value as last SFF in the control packet. Upon 678 receiving the control packet, the last SFF in the SFC will reply back 679 with relevant DIAG code. The TTL field in the NSH header could be 680 used to perform partial SFC availability. For example, the initiator 681 can set the "Your Discriminator" value to the SF that is intended to 682 be tested and set the TTL field in NSH header in a way that it expire 683 at the relevant SF. How the initiator gets the Discriminator value 684 of the SF is outside the scope of this document. 686 6.4.3. In-Situ OAM 688 [I-D.ietf-sfc-proof-of-transit] defines a mechanism to perform proof 689 of transit to securely verify if a packet traversed the relevant SFP 690 or SFC. While the mechanism is defined inband (i.e., it will be 691 included in data packets), it may be used to perform various SFC OAM 692 functions as well. 694 In-Situ OAM could be used with O bit set to perform SF availability 695 and SFC availability or performance measurement. 697 6.4.4. SFC Traceroute 699 [I-D.penno-sfc-trace] defines a protocol that checks for path 700 liveliness and traces the service hops in any SFP. Section 3 of 701 [I-D.penno-sfc-trace] defines the SFC trace packet format while 702 Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF 703 and SFF respectively. 705 An initiator can control the Service Index Limit (SIL) in SFC trace 706 packet to perform SF and SFC availability test. 708 7. Security Considerations 710 Any security consideration defined in [RFC7665] and [RFC8300] are 711 applicable for this document. 713 The OAM information from service layer at different components may 714 collectively or independently reveal sensitive information. The 715 information may reveal the type of service functions hosted in the 716 network, the classification rules and the associated service chains, 717 specific service function paths etc. The sensitivity of the 718 information from SFC layer raises a need for careful security 719 considerations 721 The mapping and the rules information at the classifier component may 722 reveal the traffic rules and the traffic mapped to the SFC. The SFC 723 information collected at an SFC component may reveal the SF 724 associated within each chain and this information together with 725 classifier rules may be used to manipulate the header of synthetic 726 attack packets that may be used to bypass the SFC and trigger any 727 internal attacks. 729 The SF information at the SF component may be used by a malicious 730 user to trigger Denial of Service (DoS) attack by overloading any 731 specific SF using rogue OAM traffic. 733 To address the above concerns, SFC and SF OAM may provide mechanism 734 for: 736 o Misuse of the OAM channel for denial-of-services, 738 o Leakage of OAM packets across SFC instances, and 740 o Leakage of SFC information beyond the SFC domain. 742 The documents proposing the OAM solution for SF component should 743 consider rate-limiting the OAM probes at a frequency guided by the 744 implementation choice. Rate-limiting may be applied at the SFF or 745 the SF . The OAM initiator may not receive a response for the probes 746 that are rate-limited resulting in false negatives and the 747 implementation should be aware of this. 749 The documents proposing the OAM solution for any service layer 750 components should consider some form of message filtering to prevent 751 leaking any internal service layer information outside the 752 administrative domain. 754 8. IANA Considerations 756 No action is required by IANA for this document. 758 9. Acknowledgements 760 We would like to thank Mohamed Boucadair, Adrian Farrel, and Greg 761 Mirsky for their review and comments. 763 10. Contributing Authors 765 Nobo Akiya 766 Ericsson 767 Email: nobo.akiya.dev@gmail.com 769 11. References 771 11.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 779 Chaining (SFC) Architecture", RFC 7665, 780 DOI 10.17487/RFC7665, October 2015, 781 . 783 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 784 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 785 May 2017, . 787 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 788 "Network Service Header (NSH)", RFC 8300, 789 DOI 10.17487/RFC8300, January 2018, 790 . 792 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 793 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 794 DOI 10.17487/RFC8459, September 2018, 795 . 797 11.2. Informative References 799 [I-D.ietf-sfc-proof-of-transit] 800 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 801 Leddy, J., Youell, S., Mozes, D., Mizrahi, T., Aguado, A., 802 and D. Lopez, "Proof of Transit", draft-ietf-sfc-proof-of- 803 transit-02 (work in progress), March 2019. 805 [I-D.penno-sfc-trace] 806 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 807 "Services Function Chaining Traceroute", draft-penno-sfc- 808 trace-03 (work in progress), September 2015. 810 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 811 RFC 792, DOI 10.17487/RFC0792, September 1981, 812 . 814 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 815 Metric for IP Performance Metrics (IPPM)", RFC 3393, 816 DOI 10.17487/RFC3393, November 2002, 817 . 819 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 820 Control Message Protocol (ICMPv6) for the Internet 821 Protocol Version 6 (IPv6) Specification", STD 89, 822 RFC 4443, DOI 10.17487/RFC4443, March 2006, 823 . 825 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 826 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 827 . 829 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 830 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 831 DOI 10.17487/RFC5881, June 2010, 832 . 834 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 835 "Bidirectional Forwarding Detection (BFD) for MPLS Label 836 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 837 June 2010, . 839 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 840 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 841 Acronym in the IETF", BCP 161, RFC 6291, 842 DOI 10.17487/RFC6291, June 2011, 843 . 845 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 846 Service Function Chaining", RFC 7498, 847 DOI 10.17487/RFC7498, April 2015, 848 . 850 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 851 Ed., "A One-Way Delay Metric for IP Performance Metrics 852 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 853 2016, . 855 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 856 Ed., "A One-Way Loss Metric for IP Performance Metrics 857 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 858 2016, . 860 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 861 Pallagatti, "Seamless Bidirectional Forwarding Detection 862 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 863 . 865 [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless 866 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, 867 and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, 868 . 870 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 871 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 872 Switched (MPLS) Data-Plane Failures", RFC 8029, 873 DOI 10.17487/RFC8029, March 2017, 874 . 876 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 877 (IPv6) Specification", STD 86, RFC 8200, 878 DOI 10.17487/RFC8200, July 2017, 879 . 881 Authors' Addresses 883 Sam K. Aldrin 884 Google 886 Email: aldrin.ietf@gmail.com 888 Carlos Pignataro (editor) 889 Cisco Systems, Inc. 891 Email: cpignata@cisco.com 893 Nagendra Kumar (editor) 894 Cisco Systems, Inc. 896 Email: naikumar@cisco.com 898 Ram Krishnan 899 VMware 901 Email: ramkri123@gmail.com 903 Anoop Ghanwani 904 Dell 906 Email: anoop@alumni.duke.edu