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