idnits 2.17.1 draft-ietf-sfc-oam-framework-13.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 (April 14, 2020) is 1473 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-03 == Outdated reference: A later version (-08) exists of draft-ietf-sfc-proof-of-transit-04 Summary: 0 errors (**), 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: October 16, 2020 N. Kumar, Ed. 6 Cisco 7 R. Krishnan 8 VMware 9 A. Ghanwani 10 Dell 11 April 14, 2020 13 Service Function Chaining (SFC) 14 Operations, Administration and Maintenance (OAM) Framework 15 draft-ietf-sfc-oam-framework-13 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 October 16, 2020. 48 Copyright Notice 50 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . 5 70 2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 9 77 3.2.2. SFC Performance Measurement . . . . . . . . . . . . . 9 78 3.3. The Classifier Component . . . . . . . . . . . . . . . . 9 79 3.4. Underlay Network . . . . . . . . . . . . . . . . . . . . 10 80 3.5. Overlay Network . . . . . . . . . . . . . . . . . . . . . 10 81 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 10 82 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 10 83 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 11 84 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 11 85 4.4. Performance Measurement Functions . . . . . . . . . . . . 12 86 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 12 87 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 12 88 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 13 89 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 13 90 6. Candidate SFC OAM Tools . . . . . . . . . . . . . . . . . . . 13 91 6.1. SFC OAM Packet Marker . . . . . . . . . . . . . . . . . . 13 92 6.2. OAM Packet Processing and Forwarding Semantic . . . . . . 14 93 6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 14 94 6.4. OAM Toolset Applicability . . . . . . . . . . . . . . . . 15 95 6.4.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . 15 96 6.4.2. BFD/Seamless-BFD . . . . . . . . . . . . . . . . . . 15 97 6.4.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . 16 98 6.4.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . 16 99 7. Manageability Considerations . . . . . . . . . . . . . . . . 16 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 103 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 106 12.2. Informative References . . . . . . . . . . . . . . . . . 19 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 109 1. Introduction 111 Service Function Chaining (SFC) enables the creation of composite 112 services that consist of an ordered set of Service Functions (SF) 113 that are to be applied to packets and/or frames selected as a result 114 of classification [RFC7665]. SFC is a concept that provides for more 115 than just the application of an ordered set of SFs to selected 116 traffic; rather, it describes a method for deploying SFs in a way 117 that enables dynamic ordering and topological independence of those 118 SFs as well as the exchange of metadata between participating 119 entities. The foundations of SFC are described in the following 120 documents: 122 o SFC Problem Statement [RFC7498] 124 o SFC Architecture [RFC7665] 126 The reader is assumed to be familiar with the material in [RFC7665]. 128 This document provides a reference framework for Operations, 129 Administration and Maintenance (OAM, [RFC6291]) of SFC. 130 Specifically, this document provides: 132 o In Section 2, an SFC layering model; 134 o In Section 3, aspects monitored by SFC OAM; 136 o In Section 4, functional requirements for SFC OAM; 138 o In Section 5, a gap analysis for SFC OAM. 140 o In Section 6, applicability of various OAM tools. 142 o In Section 7, manageability considerations for SF and SFC. 144 SFC OAM solution documents should refer to this document to indicate 145 the SFC OAM component and the functionality they target. 147 OAM controllers are assumed to be within the same administrative 148 domain as the target SFC enabled domain. 150 1.1. Document Scope 152 The focus of this document is to provide an architectural framework 153 for SFC OAM, particularly focused on the aspect of the Operations 154 component within OAM. Actual solutions and mechanisms are outside 155 the scope of this document. 157 1.2. Acronyms and Terminology 159 1.2.1. Acronyms 161 SFC: Service Function Chain 163 SFF: Service Function Forwarder 165 SF: Service Function 167 SFP: Service Function Path 169 RSP: Rendered Service Path 171 NSH: Network Service Header 173 VM: Virtual Machines 175 OAM: Operations, Administration and Maintenance 177 IPPM: IP Performance Measurement 179 BFD: Bidirectional Forwarding Detection 181 NVO3: Network Virtualization over Layer3 183 SNMP: Simple Network Management Protocol 185 NETCONF: Network Configuration Protocol 187 E-OAM: Ethernet OAM 189 MPLS_PM: MPLS Performance Measurement 191 1.2.2. Terminology 193 This document uses the terminologies defined in [RFC7665], [RFC8300], 194 and so the readers are expected to be familiar with the 195 terminologies. 197 2. SFC Layering Model 199 Multiple layers come into play for implementing the SFC. These 200 include the service layer and the underlying layers (Network Layer, 201 Link Layer, etc.). 203 o The service layer, which consists of SFC data plane elements that 204 includes classifiers, Service Functions (SF), Service Function 205 Forwarders (SFF), and SFC Proxies. This layer uses the overlay 206 network for ensuring connectivity between SFC data plane elements. 208 o The overlay network layer, which leverages various overlay network 209 technologies interconnecting SFC data plane elements and allows 210 establishing Service Function Paths (SFPs). This layer is mostly 211 transparent to the SFC data plane elements. 213 o The underlay network layer, which is dictated by the networking 214 technology deployed within a network (e.g., IP, MPLS) 216 o The link layer, which is tightly coupled with the physical 217 technology used. Ethernet is a popular choice for this layer, but 218 other alternatives are deployed (e.g. POS, DWDM). The same or 219 distinct link layer technologies may be used in each leg shown in 220 Figure 1. 222 o----------------------Service Layer----------------------o 224 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 225 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 226 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 227 +------+ 228 <------VM1------> <--VM2--> <--VM3--> 230 ^-----------------^-------------------^---------------^ Overlay 231 Network 233 o-----------------o-------------------o---------------o Underlay 234 Network 236 o--------o--------o--------o--------o--------o--------o Link 238 Figure 1: SFC Layering Example 240 In Figure 1, the service layer element such as classifier and SF are 241 depicted as virtual machines that are interconnected using an overlay 242 network. The underlay network may comprise of multiple intermediate 243 nodes but not shown in the figure that provides underlay connectivity 244 between the service layer elements. 246 While Figure 1 depicts an example where SFs are enabled as virtual 247 entities, the SFC architecture does not make any assumptions on how 248 the SFC data plane elements are deployed. The SFC architecture is 249 flexible and accommodates physical or virtual entity deployment. SFC 250 OAM accounts for this flexibility and accordingly it is applicable 251 whether SFC data plane elements are deployed directly on physical 252 hardware, as one or more Virtual Machines, or any combination 253 thereof. 255 3. SFC OAM Components 257 The SFC operates at the service layer. For the purpose of defining 258 the OAM framework, the service layer is broken up into three distinct 259 components: 261 1. SF component: OAM functions applicable at this component includes 262 testing the SFs from any SFC-aware network devices (e.g., 263 classifiers, controllers, other service nodes). Testing an SF 264 may not be restricted to connectivity to the SF, but also whether 265 the SF is providing its intended service. Refer to Section 3.1.1 266 for a more detailed discussion. 268 2. SFC component: OAM functions applicable at this component 269 includes (but are not limited to) testing the service function 270 chains and the SFPs, validation of the correlation between an SFC 271 and the actual forwarding path followed by a packet matching that 272 SFC, i.e. the Rendered Service Path (RSP). Some of the hops of 273 an SFC may not be visible when Hierarchical Service Function 274 Chaining (hSFC) [RFC8459] is in use. In such schemes, it is the 275 responsibility of the Internal Boundary Node (IBN) to glue the 276 connectivity between different levels for end-to-end OAM 277 functionality. 279 3. Classifier component: OAM functions applicable at this component 280 includes testing the validity of the classification rules and 281 detecting any incoherence among the rules installed in different 282 classifiers. 284 Figure 2 illustrates an example where OAM for the three defined 285 components are used within the SFC environment. 287 +-Classifier +-Service Function Chain OAM 288 | OAM | 289 | | ___________________________________________ 290 | \ /\ Service Function Chain \ 291 | \ / \ +---+ +---+ +-----+ +---+ \ 292 | \ / \ |SF1| |SF2| |Proxy|--|SF3| \ 293 | +------+ \/ \ +---+ +---+ +-----+ +---+ \ 294 +----> | |....(+-> ) | | | ) 295 |Classi| \ / +-----+ +-----+ +-----+ / 296 |fier | \ / | SFF1|----| SFF2|----| SFF3| / 297 | | \ / +--^--+ +-----+ +-----+ / 298 +----|-+ \/_________|________________________________/ 299 | | 300 +-------SF_OAM-------+ 301 +---+ +---+ 302 +SF_OAM>|SF3| |SF5| 303 | +-^-+ +-^-+ 304 +------|---+ | | 305 |Controller| +-SF_OAM+ 306 +----------+ 307 Service Function OAM (SF_OAM) 309 Figure 2: SFC OAM Components 311 It is expected that multiple SFC OAM solutions will be defined, each 312 targeting one specific component of the service layer. However, it 313 is critical that SFC OAM solutions together provide the coverage of 314 all three SFC OAM components: the SF component, the SFC component, 315 and the classifier component. 317 3.1. The SF Component 319 3.1.1. SF Availability 321 One SFC OAM requirement for the SF component is to allow an SFC-aware 322 network device to check the availability of a specific SF (instance), 323 located on the same or different network device(s). For cases where 324 multiple instances of an SF are used to realize a given SF for the 325 purpose of load sharing, SF availability can be performed by checking 326 the availability of any one of those instances, or the availability 327 check may be targeted at a specific instance. SF availability is an 328 aspect that raises an interesting question -- How to determine that a 329 service function is available?. On one end of the spectrum, one 330 might argue that an SF is sufficiently available if the service node 331 (physical or virtual) hosting the SF is available and is functional. 332 On the other end of the spectrum, one might argue that the SF's 333 availability can only be concluded if the packet, after passing 334 through the SF, was examined and it was verified that the packet did 335 indeed get the got expected service. 337 The former approach will likely not provide sufficient confidence to 338 the actual SF availability, i.e. a service node and a SF are two 339 different entities. The latter approach is capable of providing an 340 extensive verification, but comes at a cost. Some SFs make direct 341 modifications to packets, while others do not. Additionally, the 342 purpose of some SFs may be to, conditionally, drop packets 343 intentionally. In such cases, it is normal behavior that certain 344 packets will not be egressing out from the service function. The OAM 345 mechanism needs to take into account such SF specifics when assessing 346 SF availability. Note that there are many flavors of SFs available, 347 and many more that are likely be introduced in future. Even a given 348 SF may introduce a new functionality (e.g., a new signature in a 349 firewall). The cost of this approach is that the OAM mechanism for 350 some SF will need to be continuously modified in order to "keep up" 351 with new functionality being introduced: lack of extendibility. 353 The SF availability can be performed using a generalized approach 354 (i.e., an adequate granularity to provide a basic SF service). More 355 specifics on the mechanism to characterize SF-specific OAM to 356 validate the service offering are outside the scope of this document. 357 Those fine-grained mechanisms are implementation- and deployment- 358 specific. 360 3.1.2. SF Performance Measurement 362 The second SFC OAM requirement for the SF component is to allow an 363 SFC-aware network device to check the performance metrics such as 364 loss and delay induced by a specific SF for processing legitimate 365 traffic. The performance can be a passive measurement by using live 366 traffic or can be active measurement by using synthetic probe 367 packets. 369 On the one hand, the performance of any specific SF can be quantified 370 by measuring the loss and delay metrics of the traffic from SFF to 371 the respective SF, while on the other hand, the performance can be 372 measured by leveraging the loss and delay metrics from the respective 373 SFs. The latter requires SF involvement to perform the measurement 374 while the former does not. 376 3.2. The SFC Component 377 3.2.1. SFC Availability 379 An SFC could be comprised of varying SFs and so the OAM layer is 380 required to perform validation and verification of SFs within an SFP, 381 in addition to connectivity verification and fault isolation. 383 In order to perform service connectivity verification of an SFC/SFP, 384 the OAM functions could be initiated from any SFC-aware network 385 devices of an SFC-enabled domain for end-to-end paths, or partial 386 paths terminating on a specific SF, within the SFC/SFP. The goal of 387 this OAM function is to ensure the SFs chained together have 388 connectivity as was intended at the time when the SFC was 389 established. The necessary return codes should be defined for 390 sending back in the response to the OAM packet, in order to complete 391 the verification. 393 When ECMP is in use at the service layer for any given SFC, there 394 MUST be the ability to discover and traverse all available paths. 396 A detailed explanation of the mechanism is outside the scope of this 397 document and is expected to be included in the actual solution 398 document. 400 3.2.2. SFC Performance Measurement 402 Any SFC-aware network device should have the ability to make 403 performance measurements over the entire SFC (i.e., end-to-end) or to 404 a specific segment of SFs within the SFC. 406 3.3. The Classifier Component 408 A classifier maintains the classification rules that map a flow to a 409 specific SFC. It is vital that the classifier is correctly 410 configured with updated classification rules and is functioning as 411 expected. The SFC OAM must be able to validate the classification 412 rules by assessing whether a flow is appropriately mapped to the 413 relevant SFC. Sample OAM packets can be presented to the classifiers 414 to assess the behavior with regard to a given classification entry. 416 The Classifier availability check may be performed to check the 417 availability of the classifier to apply the rules and classify the 418 traffic flows. Any SFC-aware network device should have the ability 419 to perform availability check of the classifier component for each 420 SFC. 422 Any SFC-aware network device should have the ability to perform 423 performance measurement of the classifier component for each SFC. 425 3.4. Underlay Network 427 The underlay network provides connectivity between the SFC components 428 and so the availability or the performance of the underlay network 429 directly impacts the SFC OAM. 431 Any SFC-aware network device may have the ability to perform 432 availability check or performance measurement of the underlay 433 network. 435 3.5. Overlay Network 437 The overlay network establishes the service plane between the SFC 438 components and are mostly transparent to the SFC data plane elements. 440 Any SFC-aware network device may have the ability to perform 441 availability check or performance measurement of the overlay network. 443 4. SFC OAM Functions 445 Section 3 described SFC OAM components and the associated OAM 446 operations on each of them. This section explores SFC OAM functions 447 that are applicable for more than one SFC components. 449 The various SFC OAM requirements listed in Section 3 highlighted the 450 need for various OAM functions at the service layer. As listed in 451 Section 5.1, various OAM functions are in existence that are defined 452 to perform OAM functionality at different layers. In order to apply 453 such OAM functions at the service layer, they need to be enhanced to 454 operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in 455 multiple SFCs. 457 4.1. Connectivity Functions 459 Connectivity is mainly an on-demand function to verify that the 460 connectivity exists between certain network elements and that the SFs 461 are available. For example, LSP Ping [RFC8029] is a common tool used 462 to perform this function for an MPLS underlay network. Some of the 463 OAM functions performed by connectivity functions are as follows: 465 o Verify the Path MTU from a source to the destination SF or through 466 the SFC. This requires the ability for the OAM packet to be of 467 variable length packet size. 469 o Verify any packet re-ordering and corruption. 471 o Verify the policy of an SFC or SF. 473 o Verification and validation of forwarding paths. 475 o Proactively test alternate or protected paths to ensure 476 reliability of network configurations. 478 4.2. Continuity Functions 480 Continuity is a model where OAM messages are sent periodically to 481 validate or verify the reachability to a given SF within an SFC or 482 for the entire SFC. This allows a monitoring network device (such as 483 the classifier or controller) to quickly detect failures such as link 484 failures, network element failures, SF outages, or SFC outages. BFD 485 [RFC5880] is one such function which helps in detecting failures 486 quickly. OAM functions supported by continuity function are as 487 follows: 489 o Ability to provision continuity check to a given SF within an SFC 490 or for the entire SFC. 492 o Proactively test alternate or protected paths to ensure 493 reliability of network configurations. 495 o Notifying the detected failures to other OAM functions or 496 applications to take appropriate action. 498 4.3. Trace Functions 500 Tracing is an OAM function that allows the operation to trigger an 501 action (e.g. response generation) from every transit device (e.g. 502 SFF, SF, SFC Proxy) on the tested layer. This function is typically 503 useful for gathering information from every transit devices or for 504 isolating the failure point to a specific SF within an SFC or for an 505 entire SFC. Some of the OAM functions supported by trace functions 506 are: 508 o Ability to trigger action from every transit device at the SFC 509 layer, using TTL or other means. 511 o Ability to trigger every transit device at the SFC layer to 512 generate a response with OAM code(s), using TTL or other means. 514 o Ability to discover and traverse ECMP paths within an SFC. 516 o Ability to skip SFs that do not support OAM while tracing SFs in 517 an SFC. 519 4.4. Performance Measurement Functions 521 Performance measurement functions involve measuring of packet loss, 522 delay, delay variance, etc. These performance metrics may be 523 measured pro-actively or on-demand. 525 SFC OAM should provide the ability to measure packet loss for an SFC. 526 On-demand measurement can be used to estimate packet loss using 527 statistical methods. Measuring the loss of OAM packets, an 528 approximation of packet loss for a given SFC can be derived. 530 Delay within an SFC could be measured based on the time it takes for 531 a packet to traverse the SFC from the ingress SFC node to the egress 532 SFF. As SFCs are unidirectional in nature, measurement of one-way 533 delay [RFC7679] is important. In order to measure one-way delay, 534 time synchronization MUST be supported by means such as NTP, PTP, 535 GPS, etc. 537 One-way delay variation [RFC3393] could also be calculated by sending 538 OAM packets and measuring the jitter between the packets passing 539 through an SFC. 541 Some of the OAM functions supported by the performance measurement 542 functions are: 544 o Ability to measure the packet processing delay induced by a single 545 SF or the one-way delay to traverse an SFP bound to a given SFC. 547 o Ability to measure the packet loss [RFC7680] within an SF or an 548 SFP bound to a given SFC. 550 5. Gap Analysis 552 This section identifies various OAM functions available at different 553 layers introduced in Section 2. It also identifies various gaps that 554 exist within the current toolset for performing OAM functions 555 required for SFC. 557 5.1. Existing OAM Functions 559 There are various OAM tool sets available to perform OAM functions 560 within various layers. These OAM functions may be used to validate 561 some of the underlay and overlay networks. Tools like ping and trace 562 are in existence to perform connectivity check and tracing of 563 intermediate hops in a network. These tools support different 564 network types like IP, MPLS, TRILL, etc. There is also an effort to 565 extend the tool set to provide connectivity and continuity checks 566 within overlay networks. BFD is another tool which helps in 567 detecting data forwarding failures. Table 3 below is not exhaustive 569 Table 3: OAM Tool GAP Analysis 570 +----------------+--------------+-------------+--------+------------+ 571 | Layer | Connectivity | Continuity | Trace | Performance| 572 +----------------+--------------+-------------+--------+------------+ 573 | Underlay N/w | Ping |E-OAM, BFD | Trace | IPPM, | 574 | | | | | MPLS_PM | 575 +----------------+--------------+-------------+--------+------------+ 576 | Overlay N/w | Ping |BFD, NVo3 OAM| Trace | IPPM | 577 +----------------+--------------+-------------+--------+------------+ 578 | Classifier | Ping |BFD | Trace | None | 579 +----------------+--------------+-------------+--------+------------+ 580 | SF | None | None | None | None | 581 +----------------+--------------+-------------+--------+------------+ 582 | SFC | None | None | None | None | 583 +----------------+--------------+-------------+--------+------------+ 585 5.2. Missing OAM Functions 587 As shown in Table 3, there are no standards-based tools available for 588 the verification of SFs and SFCs. 590 5.3. Required OAM Functions 592 Primary OAM functions exist for underlying layers. Tools like ping, 593 trace, BFD, etc. exist in order to perform these OAM functions. 595 As depicted in Table 3, toolsets and solutions are required to 596 perform the OAM functions at the service layer. 598 6. Candidate SFC OAM Tools 600 This section describes the operational aspects of SFC OAM at the 601 service layer to perform the SFC OAM function defined in Section 4 602 and analyzes the applicability of various existing OAM toolsets in 603 the service layer. 605 6.1. SFC OAM Packet Marker 607 SFC OAM messages SHOULD be encapsulated with necessary SFC header and 608 with OAM markings when testing the SFC component. SFC OAM messages 609 MAY be encapsulated with the necessary SFC header and with OAM 610 markings when testing the SF component. 612 The SFC OAM function described in Section 4 performed at the service 613 layer or overlay network layer must mark the packet as an OAM packet 614 so that relevant nodes can differentiate an OAM packet from data 615 packets. The base header defined in Section 2.2 of [RFC8300] assigns 616 a bit to indicate OAM packets. When NSH encapsulation is used at the 617 service layer, the O bit must be set to differentiate the OAM packet. 618 Any other overlay encapsulations used at the service layer must have 619 a way to mark the packet as OAM packet. 621 6.2. OAM Packet Processing and Forwarding Semantic 623 Upon receiving an OAM packet, SFC-aware SFs may choose to discard the 624 packet if it does not support OAM functionality or if the local 625 policy prevents them from processing the OAM packet. When an SF 626 supports OAM functionality, it is desirable to process the packet and 627 provide an appropriate response to allow end-to-end verification. To 628 limit performance impact due to OAM, SFC-aware SFs should rate limit 629 the number of OAM packets processed. 631 An SFF may choose not to forward the OAM packet to an SF if the SF 632 does not support OAM or if the policy does not allow to forward OAM 633 packet to an SF. The SFF may choose to skip the SF, modify the 634 header and forward to next SFC node in the chain. It should be noted 635 that skipping an SF might have implication on some OAM functions 636 (e.g. the delay measurement may not be accurate). The method by 637 which an SFF detects if the connected SF supports or is allowed to 638 process OAM packets is outside the scope of this document. It could 639 be a configuration parameter instructed by the controller or it can 640 be done by dynamic negotiation between the SF and SFF. 642 If the SFF receiving the OAM packet bound to a given SFC is the last 643 SFF in the chain, it must send a relevant response to the initiator 644 of the OAM packet. Depending on the type of OAM solution and tool 645 set used, the response could be a simple response (such as ICMP 646 reply) or could include additional data from the received OAM packet 647 (like statistical data consolidated along the path). The details are 648 expected to be covered in the solution documents. 650 Any SFC-aware node that initiates an OAM packet must set the OAM 651 marker in the overlay encapsulation. 653 6.3. OAM Function Types 655 As described in Section 4, there are different OAM functions that may 656 require different OAM solutions. While the presence of the OAM 657 marker in the overlay header (e.g., O bit in the NSH header) 658 indicates it as OAM packet, it is not sufficient to indicate what OAM 659 function the packet is intended for. The Next Protocol field in NSH 660 header may be used to indicate what OAM function is intended to or 661 what toolset is used. 663 6.4. OAM Toolset Applicability 665 As described in Section 5.1, there are different tool sets available 666 to perform OAM functions at different layers. This section describes 667 the applicability of some of the available toolsets in the service 668 layer. 670 6.4.1. ICMP 672 [RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 673 networks respectively. It explains how ICMP messages can be used to 674 test the network reachability between different end points and 675 perform basic network diagnostics. 677 ICMP could be leveraged for connectivity function (defined in 678 Section 4.1) to verify the availability of SF or SFC. The Initiator 679 can generate an ICMP echo request message and control the service 680 layer encapsulation header to get the response from relevant node. 681 For example, a classifier initiating OAM can generate ICMP echo 682 request message, can set the TTL field in NSH header to 63 to get the 683 response from last SFF and thereby test the SFC availability. 684 Alternately, the initiator can set the TTL to some other value to get 685 the response from a specific SFs and thereby partially test SFC 686 availability. Alternately, the initiator could send OAM packets with 687 sequentially incrementing the TTL in the NSH to trace the SFP. 689 It could be observed that ICMP at its current stage may not be able 690 to perform all required SFC OAM functions, but as explained above, it 691 can be used for some of the connectivity functions. 693 6.4.2. BFD/Seamless-BFD 695 [RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism 696 for failure detection. [RFC5881] and [RFC5884] define the 697 applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] 698 defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. 699 [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. 701 BFD or S-BFD could be leveraged to perform continuity function for SF 702 or SFC. An initiator could generate a BFD control packet and set the 703 "Your Discriminator" value as last SFF in the control packet. Upon 704 receiving the control packet, the last SFF in the SFC will reply back 705 with relevant DIAG code. The TTL field in the NSH header could be 706 used to perform partial SFC availability. For example, the initiator 707 can set the "Your Discriminator" value to the SF that is intended to 708 be tested and set the TTL field in NSH header in a way that it 709 expires at the relevant SF. How the initiator gets the Discriminator 710 value of the SF is outside the scope of this document. 712 6.4.3. In-Situ OAM 714 [I-D.ietf-sfc-ioam-nsh] defines how In-Situ OAM data fields are 715 transported using NSH header. [I-D.ietf-sfc-proof-of-transit] 716 defines a mechanism to perform proof of transit to securely verify if 717 a packet traversed the relevant SFP or SFC. While the mechanism is 718 defined inband (i.e., it will be included in data packets), it may be 719 used to perform various SFC OAM functions as well. 721 In-Situ OAM could be used with O bit set to perform SF availability 722 and SFC availability or performance measurement. 724 6.4.4. SFC Traceroute 726 [I-D.penno-sfc-trace] defines a protocol that checks for path 727 liveliness and traces the service hops in any SFP. Section 3 of 728 [I-D.penno-sfc-trace] defines the SFC trace packet format while 729 Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF 730 and SFF respectively. While [I-D.penno-sfc-trace] has expired, the 731 proposal is implemented in Open Daylight and available. 733 An initiator can control the Service Index Limit (SIL) in SFC trace 734 packet to perform SF and SFC availability test. 736 7. Manageability Considerations 738 This document does not define any new manageability tools but 739 consolidates the manageability tool gap analysis for SF and SFC. 740 Table 4 below is not exhaustive. 742 Table 4: OAM Tool GAP Analysis 743 +----------------+--------------+-------------+--------+-------------+ 744 | Layer |Configuration |Orchestration|Topology|Notification | 745 +----------------+--------------+-------------+--------+-------------+ 746 | Underlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog,| 747 | | | | |NETCONF | 748 +----------------+--------------+-------------+--------+-------------+ 749 | Overlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog | 750 | | | | |NETCONF | 751 +----------------+--------------+-------------+--------+-------------+ 752 | Classifier | CLI, NETCONF | CLI, NETCONF| None | None | 753 +----------------+--------------+-------------+--------+-------------+ 754 | SF |CLI, NETCONF | CLI, NETCONF| None | None | 755 +----------------+--------------+-------------+--------+-------------+ 756 | SFC |CLI, NETCONF | CLI, NETCONF| None | None | 757 +----------------+--------------+-------------+--------+-------------+ 759 Configuration, orchestration and other manageability tasks of SF and 760 SFC could be performed using CLI, NETCONF, etc. 762 As depicted in Table 4, information and data models are needed for 763 configuration, manageability and orchestration for SFC. With 764 virtualized SF and SFC, manageability needs to be done 765 programmatically. 767 8. Security Considerations 769 Any security consideration defined in [RFC7665] and [RFC8300] are 770 applicable for this document. 772 The OAM information from service layer at different components may 773 collectively or independently reveal sensitive information. The 774 information may reveal the type of service functions hosted in the 775 network, the classification rules and the associated service chains, 776 specific service function paths etc. The sensitivity of the 777 information from SFC layer raises a need for careful security 778 considerations 780 The mapping and the rules information at the classifier component may 781 reveal the traffic rules and the traffic mapped to the SFC. The SFC 782 information collected at an SFC component may reveal the SF 783 associated within each chain and this information together with 784 classifier rules may be used to manipulate the header of synthetic 785 attack packets that may be used to bypass the SFC and trigger any 786 internal attacks. 788 The SF information at the SF component may be used by a malicious 789 user to trigger Denial of Service (DoS) attack by overloading any 790 specific SF using rogue OAM traffic. 792 To address the above concerns, SFC and SF OAM may provide mechanism 793 for: 795 o Misuse of the OAM channel for denial-of-services, 797 o Leakage of OAM packets across SFC instances, and 799 o Leakage of SFC information beyond the SFC domain. 801 The documents proposing the OAM solution for SF component should 802 consider rate-limiting the OAM probes at a frequency guided by the 803 implementation choice. Rate-limiting may be applied at the SFF or 804 the SF . The OAM initiator may not receive a response for the probes 805 that are rate-limited resulting in false negatives and the 806 implementation should be aware of this. 808 The documents proposing the OAM solution for any service layer 809 components should consider some form of message filtering to prevent 810 leaking any internal service layer information outside the 811 administrative domain. 813 9. IANA Considerations 815 No action is required by IANA for this document. 817 10. Acknowledgements 819 We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky, 820 Tal Mizrahi and Martin Vigoureux for their review and comments. 822 11. Contributing Authors 824 Nobo Akiya 825 Ericsson 826 Email: nobo.akiya.dev@gmail.com 828 12. References 830 12.1. Normative References 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, 834 DOI 10.17487/RFC2119, March 1997, 835 . 837 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 838 Chaining (SFC) Architecture", RFC 7665, 839 DOI 10.17487/RFC7665, October 2015, 840 . 842 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 843 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 844 May 2017, . 846 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 847 "Network Service Header (NSH)", RFC 8300, 848 DOI 10.17487/RFC8300, January 2018, 849 . 851 12.2. Informative References 853 [I-D.ietf-sfc-ioam-nsh] 854 Brockners, F. and S. Bhandari, "Network Service Header 855 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 856 ietf-sfc-ioam-nsh-03 (work in progress), March 2020. 858 [I-D.ietf-sfc-proof-of-transit] 859 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 860 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 861 transit-04 (work in progress), November 2019. 863 [I-D.penno-sfc-trace] 864 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 865 "Services Function Chaining Traceroute", draft-penno-sfc- 866 trace-03 (work in progress), September 2015. 868 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 869 RFC 792, DOI 10.17487/RFC0792, September 1981, 870 . 872 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 873 Metric for IP Performance Metrics (IPPM)", RFC 3393, 874 DOI 10.17487/RFC3393, November 2002, 875 . 877 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 878 Control Message Protocol (ICMPv6) for the Internet 879 Protocol Version 6 (IPv6) Specification", STD 89, 880 RFC 4443, DOI 10.17487/RFC4443, March 2006, 881 . 883 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 884 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 885 . 887 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 888 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 889 DOI 10.17487/RFC5881, June 2010, 890 . 892 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 893 "Bidirectional Forwarding Detection (BFD) for MPLS Label 894 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 895 June 2010, . 897 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 898 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 899 Acronym in the IETF", BCP 161, RFC 6291, 900 DOI 10.17487/RFC6291, June 2011, 901 . 903 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 904 Service Function Chaining", RFC 7498, 905 DOI 10.17487/RFC7498, April 2015, 906 . 908 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 909 Ed., "A One-Way Delay Metric for IP Performance Metrics 910 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 911 2016, . 913 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 914 Ed., "A One-Way Loss Metric for IP Performance Metrics 915 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 916 2016, . 918 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 919 Pallagatti, "Seamless Bidirectional Forwarding Detection 920 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 921 . 923 [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless 924 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, 925 and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, 926 . 928 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 929 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 930 Switched (MPLS) Data-Plane Failures", RFC 8029, 931 DOI 10.17487/RFC8029, March 2017, 932 . 934 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 935 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 936 DOI 10.17487/RFC8459, September 2018, 937 . 939 Authors' Addresses 941 Sam K. Aldrin 942 Google 944 Email: aldrin.ietf@gmail.com 946 Carlos Pignataro (editor) 947 Cisco Systems, Inc. 949 Email: cpignata@cisco.com 951 Nagendra Kumar (editor) 952 Cisco Systems, Inc. 954 Email: naikumar@cisco.com 956 Ram Krishnan 957 VMware 959 Email: ramkri123@gmail.com 961 Anoop Ghanwani 962 Dell 964 Email: anoop@alumni.duke.edu