idnits 2.17.1 draft-ietf-sfc-oam-framework-12.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 2 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 (April 10, 2020) is 1448 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: 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: October 12, 2020 N. Kumar, Ed. 6 Cisco 7 R. Krishnan 8 VMware 9 A. Ghanwani 10 Dell 11 April 10, 2020 13 Service Function Chaining (SFC) 14 Operations, Administration and Maintenance (OAM) Framework 15 draft-ietf-sfc-oam-framework-12 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 12, 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 . . . . . . . . . . . . . . . . . . 8 77 3.2.2. SFC Performance Measurement . . . . . . . . . . . . . 9 78 3.3. The Classifier Component . . . . . . . . . . . . . . . . 9 79 3.4. Underlay Network . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 18 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 Network 232 o-----------------o-------------------o---------------o Underlay Network 234 o--------o--------o--------o--------o--------o--------o Link 236 Figure 1: SFC Layering Example 238 In Figure 1, the service layer element such as classifier and SF are 239 depicted as virtual machines that are interconnected using an overlay 240 network. The underlay network may comprise of multiple intermediate 241 nodes but not shown in the figure that provides underlay connectivity 242 between the service layer elements. 244 While Figure 1 depicts an example where SFs are enabled as virtual 245 entities, the SFC architecture does not make any assumptions on how 246 the SFC data plane elements are deployed. The SFC architecture is 247 flexible and accommodates physical or virtual entity deployment. SFC 248 OAM accounts for this flexibility and accordingly it is applicable 249 whether SFC data plane elements are deployed directly on physical 250 hardware, as one or more Virtual Machines, or any combination 251 thereof. 253 3. SFC OAM Components 255 The SFC operates at the service layer. For the purpose of defining 256 the OAM framework, the service layer is broken up into three distinct 257 components: 259 1. SF component: OAM functions applicable at this component includes 260 testing the SFs from any SFC-aware network devices (e.g., 261 classifiers, controllers, other service nodes). Testing an SF 262 may not be restricted to connectivity to the SF, but also whether 263 the SF is providing its intended service. Refer to Section 3.1.1 264 for a more detailed discussion. 266 2. SFC component: OAM functions applicable at this component 267 includes (but are not limited to) testing the service function 268 chains and the SFPs, validation of the correlation between an SFC 269 and the actual forwarding path followed by a packet matching that 270 SFC, i.e. the Rendered Service Path (RSP). Some of the hops of 271 an SFC may not be visible when Hierarchical Service Function 272 Chaining (hSFC) [RFC8459] is in use. In such schemes, it is the 273 responsibility of the Internal Boundary Node (IBN) to glue the 274 connectivity between different levels for end-to-end OAM 275 functionality. 277 3. Classifier component: OAM functions applicable at this component 278 includes testing the validity of the classification rules and 279 detecting any incoherence among the rules installed in different 280 classifiers. 282 Figure 2 illustrates an example where OAM for the three defined 283 components are used within the SFC environment. 285 +-Classifier +-Service Function Chain OAM 286 | OAM | 287 | | ___________________________________________ 288 | \ /\ Service Function Chain \ 289 | \ / \ +---+ +---+ +-----+ +---+ \ 290 | \ / \ |SF1| |SF2| |Proxy|--|SF3| \ 291 | +------+ \/ \ +---+ +---+ +-----+ +---+ \ 292 +----> | |....(+-> ) | | | ) 293 |Classi| \ / +-----+ +-----+ +-----+ / 294 |fier | \ / | SFF1|----| SFF2|----| SFF3| / 295 | | \ / +--^--+ +-----+ +-----+ / 296 +----|-+ \/_________|________________________________/ 297 | | 298 +-------SF_OAM-------+ 299 +---+ +---+ 300 +SF_OAM>|SF3| |SF5| 301 | +-^-+ +-^-+ 302 +------|---+ | | 303 |Controller| +-SF_OAM+ 304 +----------+ 305 Service Function OAM (SF_OAM) 307 Figure 2: SFC OAM Components 309 It is expected that multiple SFC OAM solutions will be defined, each 310 targeting one specific component of the service layer. However, it 311 is critical that SFC OAM solutions together provide the coverage of 312 all three SFC OAM components: the SF component, the SFC component, 313 and the classifier component. 315 3.1. The SF Component 317 3.1.1. SF Availability 319 One SFC OAM requirement for the SF component is to allow an SFC-aware 320 network device to check the availability of a specific SF (instance), 321 located on the same or different network device(s). The SF 322 availability may be performed to check the availability of any 323 instance of a specific SFn or it can be a specific instance of a SF. 324 SF availability is an aspect that raises an interesting question -- 325 How to determine that a service function is available?. On one end 326 of the spectrum, one might argue that an SF is sufficiently available 327 if the service node (physical or virtual) hosting the SF is available 328 and is functional. On the other end of the spectrum, one might argue 329 that the SF's availability can only be concluded if the packet, after 330 passing through the SF, was examined and it was verified that the 331 packet did indeed get the got expected service. 333 The former approach will likely not provide sufficient confidence to 334 the actual SF availability, i.e. a service node and a SF are two 335 different entities. The latter approach is capable of providing an 336 extensive verification, but comes at a cost. Some SFs make direct 337 modifications to packets, while others do not. Additionally, the 338 purpose of some SFs may be to, conditionally, drop packets 339 intentionally. In such cases, it is normal behavior that certain 340 packets will not be egressing out from the service function. The OAM 341 mechanism needs to take into account such SF specifics when assessing 342 SF availability. Note that there are many flavors of SFs available, 343 and many more that are likely be introduced in future. Even a given 344 SF may introduce a new functionality (e.g., a new signature in a 345 firewall). The cost of this approach is that the OAM mechanism for 346 some SF will need to be continuously modified in order to "keep up" 347 with new functionality being introduced: lack of extendibility. 349 The SF availability can be performed using a generalized approach 350 (i.e., an adequate granularity to provide a basic SF service). More 351 specifics on the mechanism to characterize SF-specific OAM to 352 validate the service offering are outside the scope of this document. 353 Those fine-grained mechanisms are implementation- and deployment- 354 specific. 356 3.1.2. SF Performance Measurement 358 The second SFC OAM requirement for the SF component is to allow an 359 SFC-aware network device to check the performance metrics such as 360 loss and delay induced by a specific SF for processing legitimate 361 traffic. The performance can be a passive measurement by using live 362 traffic or can be active measurement by using synthetic probe 363 packets. 365 On the one hand, the performance of any specific SF can be quantified 366 by measuring the loss and delay metrics of the traffic from SFF to 367 the respective SF, while on the other hand, the performance can be 368 measured by leveraging the loss and delay metrics from the respective 369 SFs. The latter requires SF involvement to perform the measurement 370 while the former does not. 372 3.2. The SFC Component 374 3.2.1. SFC Availability 376 An SFC could be comprised of varying SFs and so the OAM layer is 377 required to perform validation and verification of SFs within an SFP, 378 in addition to connectivity verification and fault isolation. 380 In order to perform service connectivity verification of an SFC/SFP, 381 the OAM functions could be initiated from any SFC-aware network 382 devices of an SFC-enabled domain for end-to-end paths, or partial 383 paths terminating on a specific SF, within the SFC/SFP. The goal of 384 this OAM function is to ensure the SFs chained together have 385 connectivity as was intended at the time when the SFC was 386 established. The necessary return codes should be defined for 387 sending back in the response to the OAM packet, in order to complete 388 the verification. 390 When ECMP is in use at the service layer for any given SFC, there 391 MUST be the ability to discover and traverse all available paths. 393 A detailed explanation of the mechanism is outside the scope of this 394 document and is expected to be included in the actual solution 395 document. 397 3.2.2. SFC Performance Measurement 399 Any SFC-aware network device should have the ability to make 400 performance measurements over the entire SFC (i.e., end-to-end) or to 401 a specific segment of SFs within the SFC. 403 3.3. The Classifier Component 405 A classifier maintains the classification rules that map a flow to a 406 specific SFC. It is vital that the classifier is correctly 407 configured with updated classification rules and is functioning as 408 expected. The SFC OAM must be able to validate the classification 409 rules by assessing whether a flow is appropriately mapped to the 410 relevant SFC. Sample OAM packets can be presented to the classifiers 411 to assess the behavior with regard to a given classification entry. 413 The Classifier availability check may be performed to check the 414 availability of the classifier to apply the rules and classify the 415 traffic flows. Any SFC-aware network device should have the ability 416 to perform availability check of the classifier component for each 417 SFC. 419 Any SFC-aware network device should have the ability to perform 420 performance measurement of the classifier component for each SFC. 422 3.4. Underlay Network 424 The underlay network provides connectivity between the SFC components 425 and so the availability or the performance of the underlay network 426 directly impacts the SFC OAM. 428 Any SFC-aware network device may have the ability to perform 429 availability check or performance measurement of the underlay 430 network. 432 3.5. Overlay Network 434 The overlay network establishes the service plane between the SFC 435 components and are mostly transparent to the SFC data plane elements. 437 Any SFC-aware network device may have the ability to perform 438 availability check or performance measurement of the overlay network. 440 4. SFC OAM Functions 442 Section 3 described SFC OAM components and the associated OAM 443 operations on each of them. This section explores SFC OAM functions 444 that are applicable for more than one SFC components. 446 The various SFC OAM requirements listed in Section 3 highlighted the 447 need for various OAM functions at the service layer. As listed in 448 Section 5.1, various OAM functions are in existence that are defined 449 to perform OAM functionality at different layers. In order to apply 450 such OAM functions at the service layer, they need to be enhanced to 451 operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in 452 multiple SFCs. 454 4.1. Connectivity Functions 456 Connectivity is mainly an on-demand function to verify that the 457 connectivity exists between certain network elements and that the SFs 458 are available. For example, LSP Ping [RFC8029] is a common tool used 459 to perform this function for an MPLS underlay network. Some of the 460 OAM functions performed by connectivity functions are as follows: 462 o Verify the Path MTU from a source to the destination SF or through 463 the SFC. This requires the ability for the OAM packet to be of 464 variable length packet size. 466 o Verify any packet re-ordering and corruption. 468 o Verify the policy of an SFC or SF. 470 o Verification and validation of forwarding paths. 472 o Proactively test alternate or protected paths to ensure 473 reliability of network configurations. 475 4.2. Continuity Functions 477 Continuity is a model where OAM messages are sent periodically to 478 validate or verify the reachability to a given SF within an SFC or 479 for the entire SFC. This allows a monitoring network device (such as 480 the classifier or controller) to quickly detect failures such as link 481 failures, network element failures, SF outages, or SFC outages. BFD 482 [RFC5880] is one such function which helps in detecting failures 483 quickly. OAM functions supported by continuity function are as 484 follows: 486 o Ability to provision continuity check to a given SF within an SFC 487 or for the entire SFC. 489 o Proactively test alternate or protected paths to ensure 490 reliability of network configurations. 492 o Notifying the detected failures to other OAM functions or 493 applications to take appropriate action. 495 4.3. Trace Functions 497 Tracing is an OAM function that allows the operation to trigger an 498 action (e.g. response generation) from every transit device (e.g. 499 SFF, SF, SFC Proxy) on the tested layer. This function is typically 500 useful for gathering information from every transit devices or for 501 isolating the failure point to a specific SF within an SFC or for an 502 entire SFC. Some of the OAM functions supported by trace functions 503 are: 505 o Ability to trigger action from every transit device at the SFC 506 layer, using TTL or other means. 508 o Ability to trigger every transit device at the SFC layer to 509 generate a response with OAM code(s), using TTL or other means. 511 o Ability to discover and traverse ECMP paths within an SFC. 513 o Ability to skip SFs that do not support OAM while tracing SFs in 514 an SFC. 516 4.4. Performance Measurement Functions 518 Performance measurement functions involve measuring of packet loss, 519 delay, delay variance, etc. These performance metrics may be 520 measured pro-actively or on-demand. 522 SFC OAM should provide the ability to measure packet loss for an SFC. 523 On-demand measurement can be used to estimate packet loss using 524 statistical methods. Measuring the loss of OAM packets, an 525 approximation of packet loss for a given SFC can be derived. 527 Delay within an SFC could be measured based on the time it takes for 528 a packet to traverse the SFC from the ingress SFC node to the egress 529 SFF. As SFCs are unidirectional in nature, measurement of one-way 530 delay [RFC7679] is important. In order to measure one-way delay, 531 time synchronization MUST be supported by means such as NTP, PTP, 532 GPS, etc. 534 One-way delay variation [RFC3393] could also be calculated by sending 535 OAM packets and measuring the jitter between the packets passing 536 through an SFC. 538 Some of the OAM functions supported by the performance measurement 539 functions are: 541 o Ability to measure the packet processing delay induced by a single 542 SF or the one-way delay to traverse an SFP bound to a given SFC. 544 o Ability to measure the packet loss [RFC7680] within an SF or an 545 SFP bound to a given SFC. 547 5. Gap Analysis 549 This section identifies various OAM functions available at different 550 layers introduced in Section 2. It also identifies various gaps that 551 exist within the current toolset for performing OAM functions 552 required for SFC. 554 5.1. Existing OAM Functions 556 There are various OAM tool sets available to perform OAM functions 557 within various layers. These OAM functions may be used to validate 558 some of the underlay and overlay networks. Tools like ping and trace 559 are in existence to perform connectivity check and tracing of 560 intermediate hops in a network. These tools support different 561 network types like IP, MPLS, TRILL, etc. There is also an effort to 562 extend the tool set to provide connectivity and continuity checks 563 within overlay networks. BFD is another tool which helps in 564 detecting data forwarding failures. Table 3 below is not exhaustive 565 Table 3: OAM Tool GAP Analysis 566 +----------------+--------------+-------------+--------+------------+ 567 | Layer | Connectivity | Continuity | Trace | Performance| 568 +----------------+--------------+-------------+--------+------------+ 569 | Underlay N/w | Ping |E-OAM, BFD | Trace | IPPM, | 570 | | | | | MPLS_PM | 571 +----------------+--------------+-------------+--------+------------+ 572 | Overlay N/w | Ping |BFD, NVo3 OAM| Trace | IPPM | 573 +----------------+--------------+-------------+--------+------------+ 574 | Classifier | Ping |BFD | Trace | None | 575 +----------------+--------------+-------------+--------+------------+ 576 | SF | None | None | None | None | 577 +----------------+--------------+-------------+--------+------------+ 578 | SFC | None | None | None | None | 579 +----------------+--------------+-------------+--------+------------+ 581 5.2. Missing OAM Functions 583 As shown in Table 3, there are no standards-based tools available for 584 the verification of SFs and SFCs. 586 5.3. Required OAM Functions 588 Primary OAM functions exist for underlying layers. Tools like ping, 589 trace, BFD, etc. exist in order to perform these OAM functions. 591 As depicted in Table 3, toolsets and solutions are required to 592 perform the OAM functions at the service layer. 594 6. Candidate SFC OAM Tools 596 This section describes the operational aspects of SFC OAM at the 597 service layer to perform the SFC OAM function defined in Section 4 598 and analyzes the applicability of various existing OAM toolsets in 599 the service layer. 601 6.1. SFC OAM Packet Marker 603 SFC OAM messages SHOULD be encapsulated with necessary SFC header and 604 with OAM markings when testing the SFC component. SFC OAM messages 605 MAY be encapsulated with the necessary SFC header and with OAM 606 markings when testing the SF component. 608 The SFC OAM function described in Section 4 performed at the service 609 layer or overlay network layer must mark the packet as an OAM packet 610 so that relevant nodes can differentiate an OAM packet from data 611 packets. The base header defined in Section 2.2 of [RFC8300] assigns 612 a bit to indicate OAM packets. When NSH encapsulation is used at the 613 service layer, the O bit must be set to differentiate the OAM packet. 614 Any other overlay encapsulations used at the service layer must have 615 a way to mark the packet as OAM packet. 617 6.2. OAM Packet Processing and Forwarding Semantic 619 Upon receiving an OAM packet, SFC-aware SFs may choose to discard the 620 packet if it does not support OAM functionality or if the local 621 policy prevents them from processing the OAM packet. When an SF 622 supports OAM functionality, it is desirable to process the packet and 623 provide an appropriate response to allow end-to-end verification. To 624 limit performance impact due to OAM, SFC-aware SFs should rate limit 625 the number of OAM packets processed. 627 An SFF may choose not to forward the OAM packet to an SF if the SF 628 does not support OAM or if the policy does not allow to forward OAM 629 packet to an SF. The SFF may choose to skip the SF, modify the 630 header and forward to next SFC node in the chain. It should be noted 631 that skipping an SF might have implication on some OAM functions 632 (e.g. the delay measurement may not be accurate). The method by 633 which an SFF detects if the connected SF supports or is allowed to 634 process OAM packets is outside the scope of this document. It could 635 be a configuration parameter instructed by the controller or it can 636 be done by dynamic negotiation between the SF and SFF. 638 If the SFF receiving the OAM packet bound to a given SFC is the last 639 SFF in the chain, it must send a relevant response to the initiator 640 of the OAM packet. Depending on the type of OAM solution and tool 641 set used, the response could be a simple response (such as ICMP 642 reply) or could include additional data from the received OAM packet 643 (like statistical data consolidated along the path). The details are 644 expected to be covered in the solution documents. 646 Any SFC-aware node that initiates an OAM packet must set the OAM 647 marker in the overlay encapsulation. 649 6.3. OAM Function Types 651 As described in Section 4, there are different OAM functions that may 652 require different OAM solutions. While the presence of the OAM 653 marker in the overlay header (e.g., O bit in the NSH header) 654 indicates it as OAM packet, it is not sufficient to indicate what OAM 655 function the packet is intended for. The Next Protocol field in NSH 656 header may be used to indicate what OAM function is intended to or 657 what toolset is used. 659 6.4. OAM Toolset Applicability 661 As described in Section 5.1, there are different tool sets available 662 to perform OAM functions at different layers. This section describes 663 the applicability of some of the available toolsets in the service 664 layer. 666 6.4.1. ICMP 668 [RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 669 networks respectively. It explains how ICMP messages can be used to 670 test the network reachability between different end points and 671 perform basic network diagnostics. 673 ICMP could be leveraged for connectivity function (defined in 674 Section 4.1) to verify the availability of SF or SFC. The Initiator 675 can generate an ICMP echo request message and control the service 676 layer encapsulation header to get the response from relevant node. 677 For example, a classifier initiating OAM can generate ICMP echo 678 request message, can set the TTL field in NSH header to 255 to get 679 the response from last SFF and thereby test the SFC availability. 680 Alternately, the initiator can set the TTL to some other value to get 681 the response from a specific SFs and thereby partially test SFC 682 availability. Alternately, the initiator could send OAM packets with 683 sequentially incrementing the TTL in the NSH to trace the SFP. 685 It could be observed that ICMP at its current stage may not be able 686 to perform all required SFC OAM functions, but as explained above, it 687 can be used for some of the connectivity functions. 689 6.4.2. BFD/Seamless-BFD 691 [RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism 692 for failure detection. [RFC5881] and [RFC5884] define the 693 applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] 694 defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. 695 [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. 697 BFD or S-BFD could be leveraged to perform continuity function for SF 698 or SFC. An initiator could generate a BFD control packet and set the 699 "Your Discriminator" value as last SFF in the control packet. Upon 700 receiving the control packet, the last SFF in the SFC will reply back 701 with relevant DIAG code. The TTL field in the NSH header could be 702 used to perform partial SFC availability. For example, the initiator 703 can set the "Your Discriminator" value to the SF that is intended to 704 be tested and set the TTL field in NSH header in a way that it 705 expires at the relevant SF. How the initiator gets the Discriminator 706 value of the SF is outside the scope of this document. 708 6.4.3. In-Situ OAM 710 [I-D.ietf-sfc-ioam-nsh] defines how In-Situ OAM data fields are 711 transported using NSH header. [I-D.ietf-sfc-proof-of-transit] 712 defines a mechanism to perform proof of transit to securely verify if 713 a packet traversed the relevant SFP or SFC. While the mechanism is 714 defined inband (i.e., it will be included in data packets), it may be 715 used to perform various SFC OAM functions as well. 717 In-Situ OAM could be used with O bit set to perform SF availability 718 and SFC availability or performance measurement. 720 6.4.4. SFC Traceroute 722 [I-D.penno-sfc-trace] defines a protocol that checks for path 723 liveliness and traces the service hops in any SFP. Section 3 of 724 [I-D.penno-sfc-trace] defines the SFC trace packet format while 725 Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF 726 and SFF respectively. While [I-D.penno-sfc-trace] has expired, the 727 proposal is implemented in Open Daylight and available. 729 An initiator can control the Service Index Limit (SIL) in SFC trace 730 packet to perform SF and SFC availability test. 732 7. Manageability Considerations 734 This document does not define any new manageability tools but 735 consolidates the manageability tool gap analysis for SF and SFC. 736 Table 4 below is not exhaustive. 738 Table 4: OAM Tool GAP Analysis 739 +----------------+--------------+-------------+--------+-------------+ 740 | Layer |Configuration |Orchestration|Topology|Notification | 741 +----------------+--------------+-------------+--------+-------------+ 742 | Underlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog,| 743 | | | | |NETCONF | 744 +----------------+--------------+-------------+--------+-------------+ 745 | Overlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog | 746 | | | | |NETCONF | 747 +----------------+--------------+-------------+--------+-------------+ 748 | Classifier | CLI, NETCONF | CLI, NETCONF| None | None | 749 +----------------+--------------+-------------+--------+-------------+ 750 | SF |CLI, NETCONF | CLI, NETCONF| None | None | 751 +----------------+--------------+-------------+--------+-------------+ 752 | SFC |CLI, NETCONF | CLI, NETCONF| None | None | 753 +----------------+--------------+-------------+--------+-------------+ 754 Configuration, orchestration and other manageability tasks of SF and 755 SFC could be performed using CLI, NETCONF, etc. 757 As depicted in Table 4, information and data models are needed for 758 configuration, manageability and orchestration for SFC. With 759 virtualized SF and SFC, manageability needs to be done 760 programmatically. 762 8. Security Considerations 764 Any security consideration defined in [RFC7665] and [RFC8300] are 765 applicable for this document. 767 The OAM information from service layer at different components may 768 collectively or independently reveal sensitive information. The 769 information may reveal the type of service functions hosted in the 770 network, the classification rules and the associated service chains, 771 specific service function paths etc. The sensitivity of the 772 information from SFC layer raises a need for careful security 773 considerations 775 The mapping and the rules information at the classifier component may 776 reveal the traffic rules and the traffic mapped to the SFC. The SFC 777 information collected at an SFC component may reveal the SF 778 associated within each chain and this information together with 779 classifier rules may be used to manipulate the header of synthetic 780 attack packets that may be used to bypass the SFC and trigger any 781 internal attacks. 783 The SF information at the SF component may be used by a malicious 784 user to trigger Denial of Service (DoS) attack by overloading any 785 specific SF using rogue OAM traffic. 787 To address the above concerns, SFC and SF OAM may provide mechanism 788 for: 790 o Misuse of the OAM channel for denial-of-services, 792 o Leakage of OAM packets across SFC instances, and 794 o Leakage of SFC information beyond the SFC domain. 796 The documents proposing the OAM solution for SF component should 797 consider rate-limiting the OAM probes at a frequency guided by the 798 implementation choice. Rate-limiting may be applied at the SFF or 799 the SF . The OAM initiator may not receive a response for the probes 800 that are rate-limited resulting in false negatives and the 801 implementation should be aware of this. 803 The documents proposing the OAM solution for any service layer 804 components should consider some form of message filtering to prevent 805 leaking any internal service layer information outside the 806 administrative domain. 808 9. IANA Considerations 810 No action is required by IANA for this document. 812 10. Acknowledgements 814 We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky, 815 Tal Mizrahi and Martin Vigoureux for their review and comments. 817 11. Contributing Authors 819 Nobo Akiya 820 Ericsson 821 Email: nobo.akiya.dev@gmail.com 823 12. References 825 12.1. Normative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, 829 DOI 10.17487/RFC2119, March 1997, 830 . 832 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 833 Chaining (SFC) Architecture", RFC 7665, 834 DOI 10.17487/RFC7665, October 2015, 835 . 837 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 838 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 839 May 2017, . 841 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 842 "Network Service Header (NSH)", RFC 8300, 843 DOI 10.17487/RFC8300, January 2018, 844 . 846 12.2. Informative References 848 [I-D.ietf-sfc-ioam-nsh] 849 Brockners, F. and S. Bhandari, "Network Service Header 850 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 851 ietf-sfc-ioam-nsh-03 (work in progress), March 2020. 853 [I-D.ietf-sfc-proof-of-transit] 854 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 855 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 856 transit-04 (work in progress), November 2019. 858 [I-D.penno-sfc-trace] 859 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 860 "Services Function Chaining Traceroute", draft-penno-sfc- 861 trace-03 (work in progress), September 2015. 863 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 864 RFC 792, DOI 10.17487/RFC0792, September 1981, 865 . 867 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 868 Metric for IP Performance Metrics (IPPM)", RFC 3393, 869 DOI 10.17487/RFC3393, November 2002, 870 . 872 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 873 Control Message Protocol (ICMPv6) for the Internet 874 Protocol Version 6 (IPv6) Specification", STD 89, 875 RFC 4443, DOI 10.17487/RFC4443, March 2006, 876 . 878 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 879 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 880 . 882 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 883 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 884 DOI 10.17487/RFC5881, June 2010, 885 . 887 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 888 "Bidirectional Forwarding Detection (BFD) for MPLS Label 889 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 890 June 2010, . 892 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 893 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 894 Acronym in the IETF", BCP 161, RFC 6291, 895 DOI 10.17487/RFC6291, June 2011, 896 . 898 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 899 Service Function Chaining", RFC 7498, 900 DOI 10.17487/RFC7498, April 2015, 901 . 903 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 904 Ed., "A One-Way Delay Metric for IP Performance Metrics 905 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 906 2016, . 908 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 909 Ed., "A One-Way Loss Metric for IP Performance Metrics 910 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 911 2016, . 913 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 914 Pallagatti, "Seamless Bidirectional Forwarding Detection 915 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 916 . 918 [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless 919 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, 920 and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, 921 . 923 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 924 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 925 Switched (MPLS) Data-Plane Failures", RFC 8029, 926 DOI 10.17487/RFC8029, March 2017, 927 . 929 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 930 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 931 DOI 10.17487/RFC8459, September 2018, 932 . 934 Authors' Addresses 936 Sam K. Aldrin 937 Google 939 Email: aldrin.ietf@gmail.com 940 Carlos Pignataro (editor) 941 Cisco Systems, Inc. 943 Email: cpignata@cisco.com 945 Nagendra Kumar (editor) 946 Cisco Systems, Inc. 948 Email: naikumar@cisco.com 950 Ram Krishnan 951 VMware 953 Email: ramkri123@gmail.com 955 Anoop Ghanwani 956 Dell 958 Email: anoop@alumni.duke.edu