idnits 2.17.1 draft-ietf-sfc-oam-framework-14.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 (May 23, 2020) is 1432 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-09 == 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 (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Aldrin 3 Internet-Draft Google 4 Intended status: Informational C. Pignataro, Ed. 5 Expires: November 24, 2020 N. Kumar, Ed. 6 Cisco 7 R. Krishnan 8 VMware 9 A. Ghanwani 10 Dell 11 May 23, 2020 13 Service Function Chaining (SFC) 14 Operations, Administration and Maintenance (OAM) Framework 15 draft-ietf-sfc-oam-framework-14 17 Abstract 19 This document provides a reference framework for Operations, 20 Administration and Maintenance (OAM) for Service Function Chaining 21 (SFC). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 24, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Acronyms and Terminology . . . . . . . . . . . . . . . . 4 60 1.2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2.2. Terminology . . . . . . . . . . . . . . . . . . . . . 5 62 2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 5 63 3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. The SF Component . . . . . . . . . . . . . . . . . . . . 8 65 3.1.1. SF Availability . . . . . . . . . . . . . . . . . . . 8 66 3.1.2. SF Performance Measurement . . . . . . . . . . . . . 9 67 3.2. The SFC Component . . . . . . . . . . . . . . . . . . . . 9 68 3.2.1. SFC Availability . . . . . . . . . . . . . . . . . . 9 69 3.2.2. SFC Performance Measurement . . . . . . . . . . . . . 10 70 3.3. Classifier Component . . . . . . . . . . . . . . . . . . 10 71 3.4. Underlay Network . . . . . . . . . . . . . . . . . . . . 10 72 3.5. Overlay Network . . . . . . . . . . . . . . . . . . . . . 10 73 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 11 74 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 11 75 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 11 76 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 12 77 4.4. Performance Measurement Functions . . . . . . . . . . . . 12 78 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 13 80 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 14 81 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 14 82 6. Operational Aspects of SFC OAM at the Service Layer . . . . . 14 83 6.1. SFC OAM Packet Marker . . . . . . . . . . . . . . . . . . 14 84 6.2. OAM Packet Processing and Forwarding Semantic . . . . . . 15 85 6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 16 86 7. Candidate SFC OAM Tools . . . . . . . . . . . . . . . . . . . 16 87 7.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 7.2. BFD/Seamless-BFD . . . . . . . . . . . . . . . . . . . . 16 89 7.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . . . 17 90 7.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . . . 17 91 8. Manageability Considerations . . . . . . . . . . . . . . . . 18 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 95 12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 96 13. Informative References . . . . . . . . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 99 1. Introduction 101 Service Function Chaining (SFC) enables the creation of composite 102 services that consist of an ordered set of Service Functions (SF) 103 that are to be applied to any traffic selected as a result of 104 classification [RFC7665]. SFC is a concept that provides for more 105 than just the application of an ordered set of SFs to selected 106 traffic; rather, it describes a method for deploying SFs in a way 107 that enables dynamic ordering and topological independence of those 108 SFs as well as the exchange of metadata between participating 109 entities. The foundations of SFC are described in the following 110 documents: 112 o SFC Problem Statement [RFC7498] 114 o SFC Architecture [RFC7665] 116 The reader is assumed to be familiar with the material in [RFC7665]. 118 This document provides a reference framework for Operations, 119 Administration and Maintenance (OAM, [RFC6291]) of SFC. 120 Specifically, this document provides: 122 o In Section 2, an SFC layering model; 124 o In Section 3, aspects monitored by SFC OAM; 126 o In Section 4, functional requirements for SFC OAM; 128 o In Section 5, a gap analysis for SFC OAM. 130 o In Section 6, operational aspects of SFC OAM at the service layer. 132 o In Section 7, applicability of various OAM tools. 134 o In Section 8, manageability considerations for SF and SFC. 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 SFC-aware network devices that are capable of 140 generating OAM packets. They should be within the same 141 administrative domain as the target SFC enabled domain. 143 1.1. Document Scope 145 The focus of this document is to provide an architectural framework 146 for SFC OAM, particularly focused on the aspect of the Operations 147 component within OAM. Actual solutions and mechanisms are outside 148 the scope of this document. 150 1.2. Acronyms and Terminology 152 1.2.1. Acronyms 154 SFC: Service Function Chain 156 SFF: Service Function Forwarder 158 SF: Service Function 160 SFP: Service Function Path 162 RSP: Rendered Service Path 164 NSH: Network Service Header 166 VM: Virtual Machines 168 OAM: Operations, Administration and Maintenance 170 IPPM: IP Performance Measurement 172 BFD: Bidirectional Forwarding Detection 174 NVO3: Network Virtualization over Layer3 176 SNMP: Simple Network Management Protocol 178 NETCONF: Network Configuration Protocol 180 E-OAM: Ethernet OAM 182 MPLS_PM: MPLS Performance Measurement 184 POS: Packet over SONET 186 DWDM: Dense Wavelength Division Multiplexing 188 hSFC: Hierarchical Service Function Chaining 190 IBN: Internal Boundary Node 191 MPLS: Multiprotocol Label Switching 193 TRILL: Transparent Interconnection of Lots of Links 195 CLI: Command Line Interface 197 1.2.2. Terminology 199 This document uses the terminologies defined in [RFC7665], [RFC8300], 200 and so the readers are expected to be familiar with the 201 terminologies. 203 2. SFC Layering Model 205 Multiple layers come into play for implementing the SFC. These 206 include the service layer and the underlying layers (Network Layer, 207 Link Layer, etc.). 209 o The service layer, which consists of SFC data plane elements that 210 includes classifiers, Service Functions (SF), Service Function 211 Forwarders (SFF), and SFC Proxies. This layer uses the overlay 212 network layer for ensuring connectivity between SFC data plane 213 elements. 215 o The overlay network layer, which leverages various overlay network 216 technologies (e.g., VxLAN)interconnecting SFC data plane elements 217 and allows establishing Service Function Paths (SFPs). This layer 218 is mostly transparent to the SFC data plane elements as not all 219 the data plane elements process the overlay header. 221 o The underlay network layer, which is dictated by the networking 222 technology deployed within a network (e.g., IP, MPLS) 224 o The link layer, which is tightly coupled with the physical 225 technology used. Ethernet is one such choice for this layer, but 226 other alternatives are deployed (e.g. POS, DWDM). In a virtual 227 environment, virtualized I/O technologies such as SR-IOV or 228 similar are also applicable for this layer. The same or distinct 229 link layer technologies may be used in each leg shown in Figure 1. 231 o----------------------Service Layer----------------------o 233 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 234 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 235 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 236 +------+ 237 <------VM1------> <--VM2--> <--VM3--> 239 ^-----------------^-------------------^---------------^ Overlay 240 Network 242 o-----------------o-------------------o---------------o Underlay 243 Network 245 o--------o--------o--------o----------o-------o-------o Link 247 Figure 1: SFC Layering Example 249 In Figure 1, the service layer elements such as classifier and SF are 250 depicted as virtual entities that are interconnected using an overlay 251 network. The underlay network may comprise multiple intermediate 252 nodes not shown in the figure that provide underlay connectivity 253 between the service layer elements. 255 While Figure 1 depicts an example where SFs are enabled as virtual 256 entities, the SFC architecture does not make any assumptions on how 257 the SFC data plane elements are deployed. The SFC architecture is 258 flexible and accommodates physical or virtual entity deployment. SFC 259 OAM accounts for this flexibility and accordingly it is applicable 260 whether SFC data plane elements are deployed directly on physical 261 hardware, as one or more Virtual entities, or any combination 262 thereof. 264 3. SFC OAM Components 266 The SFC operates at the service layer. For the purpose of defining 267 the OAM framework, the service layer is broken up into three distinct 268 components: 270 1. SF component: OAM functions applicable at this component include 271 testing the SFs from any SFC-aware network device (e.g., 272 classifiers, controllers, other service nodes). Testing an SF 273 may be more expansive than just checking connectivity to the SF 274 such as checking if the SF is providing its intended service. 275 Refer to Section 3.1.1 for a more detailed discussion. 277 2. SFC component: OAM functions applicable at this component include 278 (but are not limited to) testing the service function chains and 279 the SFPs, validation of the correlation between an SFC and the 280 actual forwarding path followed by a packet matching that SFC, 281 i.e. the Rendered Service Path (RSP). Some of the hops of an SFC 282 may not be visible when Hierarchical Service Function Chaining 283 (hSFC) [RFC8459] is in use. In such schemes, it is the 284 responsibility of the Internal Boundary Node (IBN) to glue the 285 connectivity between different levels for end-to-end OAM 286 functionality. 288 3. Classifier component: OAM functions applicable at this component 289 include testing the validity of the classification rules and 290 detecting any incoherence among the rules installed when more 291 than one classifier is used as explained in Section 2.2 of 292 [RFC7665] . 294 Figure 2 illustrates an example where OAM for the three defined 295 components are used within the SFC environment. 297 +-Classifier +-Service Function Chain OAM 298 | OAM | 299 | | ___________________________________________ 300 | \ /\ Service Function Chain \ 301 | \ / \ +---+ +---+ +-----+ +---+ \ 302 | \ / \ |SF1| |SF2| |Proxy|--|SF3| \ 303 | +------+ \/ \ +---+ +---+ +-----+ +---+ \ 304 +----> | |....(+-> ) | | | ) 305 |Classi| \ / +-----+ +-----+ +-----+ / 306 |fier | \ / | SFF1|----| SFF2|----| SFF3| / 307 | | \ / +--^--+ +-----+ +-----+ / 308 +----|-+ \/_________|________________________________/ 309 | | 310 +-------SF_OAM-------+ 311 +---+ +---+ 312 +SF_OAM>|SF3| |SF5| 313 | +-^-+ +-^-+ 314 +------|---+ | | 315 |Controller| +-SF_OAM+ 316 +----------+ 317 Service Function OAM (SF_OAM) 319 Figure 2: SFC OAM Components 321 It is expected that multiple SFC OAM solutions will be defined, each 322 targeting one specific component of the service layer. However, it 323 is critical that SFC OAM solutions together provide the coverage of 324 all three SFC OAM components: the SF component, the SFC component, 325 and the classifier component. 327 3.1. The SF Component 329 3.1.1. SF Availability 331 One SFC OAM requirement for the SF component is to allow an SFC-aware 332 network device to check the availability of a specific SF (instance), 333 located on the same or different network device(s). For cases where 334 multiple instances of an SF are used to realize a given SF for the 335 purpose of load sharing, SF availability can be performed by checking 336 the availability of any one of those instances, or the availability 337 check may be targeted at a specific instance. SF availability is an 338 aspect that raises an interesting question: How does one determine 339 that a service function is available? On one end of the spectrum, 340 one might argue that an SF is sufficiently available if the service 341 node (physical or virtual) hosting the SF is available and is 342 functional. On the other end of the spectrum, one might argue that 343 the SF's availability can only be concluded if the packet, after 344 passing through the SF, was examined and it was verified that the 345 packet did indeed get the expected service. 347 The former approach will likely not provide sufficient confidence to 348 the actual SF availability, i.e. a service node and an SF are two 349 different entities. The latter approach is capable of providing an 350 extensive verification, but comes at a cost. Some SFs make direct 351 modifications to packets, while others do not. Additionally, the 352 purpose of some SFs may be to, conditionally, drop packets 353 intentionally. In such cases, it is normal behavior that certain 354 packets will not be egressing out from the service function. The OAM 355 mechanism needs to take into account such SF specifics when assessing 356 SF availability. Note that there are many flavors of SFs available, 357 and many more that are likely be introduced in future. Even a given 358 SF may introduce a new functionality (e.g., a new signature in a 359 firewall). The cost of this approach is that the OAM mechanism for 360 some SF will need to be continuously modified in order to "keep up" 361 with new functionality being introduced: lack of extensibility. 363 The SF availability check can be performed using a generalized 364 approach (i.e., an adequate granularity to provide a basic SF 365 service). The task of evaluating the true availability of a Service 366 Function is a complex activity, currently having no simple, unified 367 solution. There is currently no standard means of doing so. Any 368 such mechanism would be far from a typical OAM function, so it is not 369 explored as part of the analysis in Sections 4 and 5. 371 3.1.2. SF Performance Measurement 373 The second SFC OAM requirement for the SF component is to allow an 374 SFC-aware network device to check the performance metrics such as 375 loss and delay induced by a specific SF for processing legitimate 376 traffic. The performance can be a passive measurement by using live 377 traffic, an active measurement by using synthetic probe packets or 378 can be a hybrid method that use a combination of active and passive 379 measurement. More details about this OAM function is explained in 380 Section 4.4. 382 On the one hand, the performance of any specific SF can be quantified 383 by measuring the loss and delay metrics of the traffic from SFF to 384 the respective SF, while on the other hand, the performance can be 385 measured by leveraging the loss and delay metrics from the respective 386 SFs. The latter requires SF involvement to perform the measurement 387 while the former does not. For cases where multiple instances of an 388 SF are used to realize a given SF for the purpose of load sharing, SF 389 performance can be quantified by measuring the metrics for any one 390 instance of SF or by measuring the metrics for a specific instance. 392 The metrics measured to quantify the performance of the SF component 393 are not just limited to loss and delay. Other metrics such as 394 throughput also exist and the choice of metrics for performance 395 measurement is outside the scope of this document. 397 3.2. The SFC Component 399 3.2.1. SFC Availability 401 An SFC could comprise varying SFs and so the OAM layer is required to 402 perform validation and verification of SFs within an SFP, in addition 403 to connectivity verification and fault isolation. 405 In order to perform service connectivity verification of an SFC/SFP, 406 the OAM functions could be initiated from any SFC-aware network 407 device of an SFC-enabled domain for end-to-end paths, or partial 408 paths terminating on a specific SF, within the SFC/SFP. The goal of 409 this OAM function is to ensure the SFs chained together have 410 connectivity as was intended at the time when the SFC was 411 established. The necessary return codes should be defined for 412 sending back in the response to the OAM packet, in order to complete 413 the verification. 415 When ECMP is in use at the service layer for any given SFC, there 416 must be the ability to discover and traverse all available paths. 418 A detailed explanation of the mechanism is outside the scope of this 419 document and is expected to be included in the actual solution 420 document. 422 3.2.2. SFC Performance Measurement 424 Any SFC-aware network device should have the ability to make 425 performance measurements over the entire SFC (i.e., end-to-end) or to 426 a specific segment of SFs within the SFC. 428 3.3. Classifier Component 430 A classifier maintains the classification rules that map a flow to a 431 specific SFC. It is vital that the classifier is correctly 432 configured with updated classification rules and is functioning as 433 expected. The SFC OAM must be able to validate the classification 434 rules by assessing whether a flow is appropriately mapped to the 435 relevant SFC and detect any misclassification. Sample OAM packets 436 can be presented to the classifiers to assess the behavior with 437 regard to a given classification entry. 439 The classifier availability check may be performed to check the 440 availability of the classifier to apply the rules and classify the 441 traffic flows. Any SFC-aware network device should have the ability 442 to perform availability checking of the classifier component for each 443 SFC. 445 Any SFC-aware network device should have the ability to perform 446 performance measurement of the classifier component for each SFC. 447 The performance can be quantified by measuring the performance 448 metrics of the traffic from the classifier for each SFC/SFP. 450 3.4. Underlay Network 452 The underlay network provides connectivity between the SFC components 453 so the availability or the performance of the underlay network 454 directly impacts the SFC OAM. 456 Any SFC-aware network device may have the ability to perform 457 availability check or performance measurement of the underlay network 458 using any existing OAM functions listed in Section 5.1. 460 3.5. Overlay Network 462 The overlay network provides connectivity for service plane between 463 the SFC components and is mostly transparent to the SFC data plane 464 elements. 466 Any SFC-aware network device may have the ability to perform 467 availability check or performance measurement of the overlay network 468 using any existing OAM functions listed in Section 5.1. 470 4. SFC OAM Functions 472 Section 3 described SFC OAM components and the associated OAM 473 operations on each of them. This section explores SFC OAM functions 474 that are applicable for more than one SFC component. 476 The various SFC OAM requirements listed in Section 3 highlighted the 477 need for various OAM functions at the service layer. As listed in 478 Section 5.1, various OAM functions are in existence that are defined 479 to perform OAM functionality at different layers. In order to apply 480 such OAM functions at the service layer, they need to be enhanced to 481 operate a single SF/SFF to multiple SFs/SFFs spanning across one or 482 more SFCs. 484 4.1. Connectivity Functions 486 Connectivity is mainly an on-demand function to verify that the 487 connectivity exists between certain network elements and that the SFs 488 are available. For example, LSP Ping [RFC8029] is a common tool used 489 to perform this function for an MPLS network. Some of the OAM 490 functions performed by connectivity functions are as follows: 492 o Verify the Path MTU from a source to the destination SF or through 493 the SFC. This requires the ability for the OAM packet to be of 494 variable length. 496 o Detect any packet re-ordering and corruption. 498 o Verify that an SFC or SF is applying the expected policy. 500 o Verification and validation of forwarding paths. 502 o Proactively test alternate or protected paths to ensure 503 reliability of network configurations. 505 4.2. Continuity Functions 507 Continuity is a model where OAM messages are sent periodically to 508 validate or verify the reachability of a given SF within an SFC or 509 for the entire SFC. This allows a monitoring network device (such as 510 the classifier or controller) to quickly detect failures such as link 511 failures, network element failures, SF outages, or SFC outages. BFD 512 [RFC5880] is one such function which helps in detecting failures 513 quickly. OAM functions supported by continuity functions are as 514 follows: 516 o Ability to provision a continuity check to a given SF within an 517 SFC or for the entire SFC. 519 o Proactively test alternate or protected paths to ensure 520 reliability of network configurations. 522 o Notifying other OAM functions or applications of the detected 523 failures so they can take appropriate action. 525 4.3. Trace Functions 527 Tracing is an OAM function that allows the operation to trigger an 528 action (e.g. response generation) from every transit device (e.g. 529 SFF, SF, SFC Proxy) on the tested layer. This function is typically 530 useful for gathering information from every transit device or for 531 isolating the failure point to a specific SF within an SFC or for an 532 entire SFC. Some of the OAM functions supported by trace functions 533 are: 535 o Ability to trigger an action from every transit device at the SFC 536 layer, using TTL or other means. 538 o Ability to trigger every transit device at the SFC layer to 539 generate a response with OAM code(s), using TTL or other means. 541 o Ability to discover and traverse ECMP paths within an SFC. 543 o Ability to skip SFs that do not support OAM while tracing SFs in 544 an SFC. 546 4.4. Performance Measurement Functions 548 Performance measurement functions involve measuring of packet loss, 549 delay, delay variance, etc. These performance metrics may be 550 measured pro-actively or on-demand. 552 SFC OAM should provide the ability to measure packet loss for an SFC. 553 On-demand measurement can be used to estimate packet loss using 554 statistical methods. To ensure accurate estimations, one needs to 555 ensure that OAM packets are treated the same and also share the same 556 fate as regular data traffic. 558 Delay within an SFC could be measured based on the time it takes for 559 a packet to traverse the SFC from the ingress SFC node to the egress 560 SFF. Measurement protocols such as One-way Active Measurement 561 Protocol (OWAMP) [RFC4656] and Two-way Active Measurement Protocol 562 (TWAMP) [RFC5357] can be used to measure the characteristics. As 563 SFCs are unidirectional in nature, measurement of one-way delay 564 [RFC7679] is important. In order to measure one-way delay, time 565 synchronization must be supported by means such as NTP, GPS, 566 Precision Time Protocol (PTP), etc. 568 One-way delay variation [RFC3393] could also be calculated by sending 569 OAM packets and measuring the jitter for traffic passing through an 570 SFC. 572 Some of the OAM functions supported by the performance measurement 573 functions are: 575 o Ability to measure the packet processing delay induced by a single 576 SF or the one-way delay to traverse an SFP bound to a given SFC. 578 o Ability to measure the packet loss [RFC7680] within an SF or an 579 SFP bound to a given SFC. 581 5. Gap Analysis 583 This section identifies various OAM functions available at different 584 layers introduced in Section 2. It also identifies various gaps that 585 exist within the current toolset for performing OAM functions 586 required for SFC. 588 5.1. Existing OAM Functions 590 There are various OAM tool sets available to perform OAM functions 591 within various layers. These OAM functions may be used to validate 592 some of the underlay and overlay networks. Tools like ping and trace 593 are in existence to perform connectivity check and tracing of 594 intermediate hops in a network. These tools support different 595 network types like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM) 596 [Y.1731] [EFM] and Connectivity Fault Management (CFM) [CFM] offers 597 OAM mechanisms such as an Ethernet continuity check for Ethernet 598 links. There is an effort around NVO3 OAM to provide connectivity 599 and continuity checks for networks that use NVO3. BFD is used for 600 the detection of data plane forwarding failures. The IPPM framework 601 [RFC2330] offers tools such as OWAMP [RFC4656] and TWAMP [RFC5357] 602 (collectively referred as IPPM in this section) to measure various 603 performance metrics. MPLS Packet Loss Measurement (LM) and Packet 604 Delay Measurement (DM) (collectively referred as MPLS_PM in this 605 section) [RFC6374] offers the ability to measure performance metrics 606 in MPLS network. There is also an effort to extend the tool set to 607 provide connectivity and continuity checks within overlay networks. 609 BFD is another tool which helps in detecting data forwarding 610 failures. Table 3 below is not exhaustive. 612 Table 3: OAM Tool GAP Analysis 613 +----------------+--------------+-------------+--------+------------+ 614 | Layer | Connectivity | Continuity | Trace | Performance| 615 +----------------+--------------+-------------+--------+------------+ 616 | Underlay N/w | Ping |E-OAM, BFD | Trace | IPPM, | 617 | | | | | MPLS_PM | 618 +----------------+--------------+-------------+--------+------------+ 619 | Overlay N/w | Ping | BFD, | | | 620 | | | NVO3 OAM | Trace | IPPM | 621 +----------------+--------------+-------------+--------+------------+ 622 | Classifier | Ping | BFD | Trace | None | 623 +----------------+--------------+-------------+--------+------------+ 624 | SF | None | None | None | None | 625 +----------------+--------------+-------------+--------+------------+ 626 | SFC | None | None | None | None | 627 +----------------+--------------+-------------+--------+------------+ 629 5.2. Missing OAM Functions 631 As shown in Table 3, there are no standards-based tools available at 632 the time of this writing that can be used natively (i.e. without 633 enhancement) for the verification of SFs and SFCs. 635 5.3. Required OAM Functions 637 Primary OAM functions exist for underlying layers. Tools like ping, 638 trace, BFD, etc. exist in order to perform these OAM functions. 640 As depicted in Table 3, toolsets and solutions are required to 641 perform the OAM functions at the service layer. 643 6. Operational Aspects of SFC OAM at the Service Layer 645 This section describes the operational aspects of SFC OAM at the 646 service layer to perform the SFC OAM function defined in Section 4 647 and analyzes the applicability of various existing OAM toolsets in 648 the service layer. 650 6.1. SFC OAM Packet Marker 652 SFC OAM messages should be encapsulated with necessary SFC header and 653 with OAM markings when testing the SFC component. SFC OAM messages 654 may be encapsulated with the necessary SFC header and with OAM 655 markings when testing the SF component. 657 The SFC OAM function described in Section 4 performed at the service 658 layer or overlay network layer must mark the packet as an OAM packet 659 so that relevant nodes can differentiate an OAM packet from data 660 packets. The base header defined in Section 2.2 of [RFC8300] assigns 661 a bit to indicate OAM packets. When NSH encapsulation is used at the 662 service layer, the O bit must be set to differentiate the OAM packet. 663 Any other overlay encapsulations used at the service layer must have 664 a way to mark the packet as OAM packet. 666 6.2. OAM Packet Processing and Forwarding Semantic 668 Upon receiving an OAM packet, SFC-aware SFs may choose to discard the 669 packet if it does not support OAM functionality or if the local 670 policy prevents them from processing the OAM packet. When an SF 671 supports OAM functionality, it is desirable to process the packet and 672 provide an appropriate response to allow end-to-end verification. To 673 limit performance impact due to OAM, SFC-aware SFs should rate limit 674 the number of OAM packets processed. 676 An SFF may choose not to forward the OAM packet to an SF if the SF 677 does not support OAM or if the policy does not allow to forward OAM 678 packets to an SF. The SFF may choose to skip the SF, modify the 679 header and forward to the next SFC node in the chain. It should be 680 noted that skipping an SF might have implications on some OAM 681 functions (e.g. the delay measurement may not be accurate). The 682 method by which an SFF detects if the connected SF supports or is 683 allowed to process OAM packets is outside the scope of this document. 684 It could be a configuration parameter instructed by the controller or 685 it can be done by dynamic negotiation between the SF and SFF. 687 If the SFF receiving the OAM packet bound to a given SFC is the last 688 SFF in the chain, it must send a relevant response to the initiator 689 of the OAM packet. Depending on the type of OAM solution and tool 690 set used, the response could be a simple response (such as ICMP 691 reply) or could include additional data from the received OAM packet 692 (like statistical data consolidated along the path). The details are 693 expected to be covered in the solution documents. 695 Any SFC-aware node that initiates an OAM packet must set the OAM 696 marker in the overlay encapsulation. 698 6.3. OAM Function Types 700 As described in Section 4, there are different OAM functions that may 701 require different OAM solutions. While the presence of the OAM 702 marker in the overlay header (e.g., O bit in the NSH header) 703 indicates it as an OAM packet, it is not sufficient to indicate what 704 OAM function the packet is intended for. The Next Protocol field in 705 the NSH header may be used to indicate what OAM function is intended 706 or what toolset is used. Any other overlay encapsulations used at 707 the service layer must have a similar way to indicate the intended 708 OAM function. 710 7. Candidate SFC OAM Tools 712 As described in Section 5.1, there are different tool sets available 713 to perform OAM functions at different layers. This section describe 714 the applicability of some of the available toolsets in the service 715 layer. 717 7.1. ICMP 719 [RFC0792] and [RFC4443] describe the use of ICMP in IPv4 and IPv6 720 networks respectively. It explains how ICMP messages can be used to 721 test the network reachability between different end points and 722 perform basic network diagnostics. 724 ICMP could be leveraged for connectivity functions (defined in 725 Section 4.1) to verify the availability of an SF or SFC. The 726 Initiator can generate an ICMP echo request message and control the 727 service layer encapsulation header to get the response from the 728 relevant node. For example, a classifier initiating OAM can generate 729 an ICMP echo request message, can set the TTL field in the NSH header 730 [RFC8300] to 63 to get the response from the last SFF, and thereby 731 test the SFC availability. Alternatively, the initiator can set the 732 TTL to some other value to get the response from a specific SFs and 733 thereby partially test SFC availability or the initiator could send 734 OAM packets with sequentially incrementing TTL in the NSH to trace 735 the SFP. 737 It could be observed that ICMP at its current stage may not be able 738 to perform all required SFC OAM functions, but as explained above, it 739 can be used for some of the connectivity functions. 741 7.2. BFD/Seamless-BFD 743 [RFC5880] defines the Bidirectional Forwarding Detection (BFD) 744 mechanism for failure detection. [RFC5881] and [RFC5884] define the 745 applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] 746 defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. 747 [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. 749 BFD or S-BFD could be leveraged to perform the continuity function 750 for SF or SFC. An initiator could generate a BFD control packet and 751 set the "Your Discriminator" value to identify the last SFF in the 752 control packet. Upon receiving the control packet, the last SFF in 753 the SFC will reply back with the relevant DIAG code. The TTL field 754 in the NSH header could be used to perform a partial SFC availability 755 check. For example, the initiator can set the "Your Discriminator" 756 value to identify the SF that is intended to be tested and set the 757 TTL field in the NSH header in a way that it expires at the relevant 758 SF. How the initiator gets the Discriminator value to identify the 759 SF is outside the scope of this document. 761 7.3. In-Situ OAM 763 [I-D.ietf-sfc-ioam-nsh] defines how In-Situ OAM data fields 764 [I-D.ietf-ippm-ioam-data] are transported using the NSH header. 765 [I-D.ietf-sfc-proof-of-transit] defines a mechanism to perform proof 766 of transit to securely verify if a packet traversed the relevant SFP 767 or SFC. While the mechanism is defined inband (i.e., it will be 768 included in data packets), IOA Option-Types such as IOAM Trace 769 Option-Types can also be used to perform other SFC OAM function such 770 as SFC tracing. 772 In-Situ OAM could be leveraged to perform SF availability and SFC 773 availability or performance measurement. For example, if SFC is 774 realized using NSH, the O-bit in the NSH header could be set to 775 indicate the OAM traffic as defined in Section 4.2 776 [I-D.ietf-sfc-ioam-nsh]. 778 7.4. SFC Traceroute 780 [I-D.penno-sfc-trace] defines a protocol that checks for path 781 liveliness and traces the service hops in any SFP. Section 3 of 782 [I-D.penno-sfc-trace] defines the SFC trace packet format while 783 Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF 784 and SFF respectively. While [I-D.penno-sfc-trace] has expired, the 785 proposal is implemented in Open Daylight and is available. 787 An initiator can control the Service Index Limit (SIL) in SFC trace 788 packet to perform SF and SFC availability test. 790 8. Manageability Considerations 792 This document does not define any new manageability tools but 793 consolidates the manageability tool gap analysis for SF and SFC. 794 Table 4 below is not exhaustive. 796 Table 4: OAM Tool GAP Analysis 797 +----------------+--------------+-------------+--------+-------------+ 798 | Layer |Configuration |Orchestration|Topology|Notification | 799 +----------------+--------------+-------------+--------+-------------+ 800 | Underlay N/w |CLI, NETCONF | CLI, NETCONF| SNMP |SNMP, Syslog,| 801 | | | | |NETCONF | 802 +----------------+--------------+-------------+--------+-------------+ 803 | Overlay N/w |CLI, NETCONF | CLI, NETCONF| SNMP |SNMP, Syslog | 804 | | | | |NETCONF | 805 +----------------+--------------+-------------+--------+-------------+ 806 | Classifier |CLI, NETCONF | CLI, NETCONF| None | None | 807 +----------------+--------------+-------------+--------+-------------+ 808 | SF |CLI, NETCONF | CLI, NETCONF| None | None | 809 +----------------+--------------+-------------+--------+-------------+ 810 | SFC |CLI, NETCONF | CLI, NETCONF| None | None | 811 +----------------+--------------+-------------+--------+-------------+ 813 Configuration, orchestration and other manageability tasks of SF and 814 SFC could be performed using CLI, NETCONF [RFC6241] , etc. 816 While the NETCONF capabilities are readily available as depicted in 817 Table 4, the information and data models are needed for 818 configuration, manageability and orchestration for SFC. With 819 virtualized SF and SFC, manageability needs to be done 820 programmatically. 822 9. Security Considerations 824 Any security considerations defined in [RFC7665] and [RFC8300] is 825 applicable for this document. 827 The OAM information from the service layer at different components 828 may collectively or independently reveal sensitive information. The 829 information may reveal the type of service functions hosted in the 830 network, the classification rules and the associated service chains, 831 specific service function paths, etc. The sensitivity of the 832 information from the SFC layer raises a need for careful security 833 considerations. 835 The mapping and the rules information at the classifier component may 836 reveal the traffic rules and the traffic mapped to the SFC. The SFC 837 information collected at an SFC component may reveal the SFs 838 associated within each chain and this information together with 839 classifier rules may be used to manipulate the header of synthetic 840 attack packets that may be used to bypass the SFC and trigger any 841 internal attacks. 843 The SF information at the SF component may be used by a malicious 844 user to trigger Denial of Service (DoS) attack by overloading any 845 specific SF using rogue OAM traffic. 847 To address the above concerns, SFC and SF OAM should provide 848 mechanisms for mitigating: 850 o Misuse of the OAM channel for denial-of-services, 852 o Leakage of OAM packets across SFC instances, and 854 o Leakage of SFC information beyond the SFC domain. 856 The documents proposing the OAM solution for SF components should 857 provide rate-limiting the OAM probes at a frequency guided by the 858 implementation choice. Rate-limiting may be applied at the 859 Classifier, SFF or the SF . The OAM initiator may not receive a 860 response for the probes that are rate-limited resulting in false 861 negatives and the implementation should be aware of this. To 862 mitigate any attacks that leverage OAM packets, future documents 863 proposing OAM solutions should describe the use of any technique to 864 detect and mitigate anomalies and various security attacks. 866 The documents proposing the OAM solution for any service layer 867 components should consider some form of message filtering to prevent 868 leaking any internal service layer information outside the 869 administrative domain. 871 10. IANA Considerations 873 No action is required by IANA for this document. 875 11. Acknowledgements 877 We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky, 878 Tal Mizrahi, Martin Vigoureux, Tirumaleswar Reddy, Carlos Bernados, 879 Martin Duke, Barry Leiba, Eric Vyncke, Roman Danyliw, Erik Kline, 880 Benjamin Kaduk, Robert Wilton, Frank Brockner, Alvaro Retana, Murray 881 Kucherawy, and Alissa Cooper for their review and comments. 883 12. Contributing Authors 885 Nobo Akiya 886 Ericsson 887 Email: nobo.akiya.dev@gmail.com 889 13. Informative References 891 [CFM] IEEE, ""Connectivity Fault Management clause of IEEE 892 Standard for Local and Metropolitan Area Networks--Bridges 893 and Bridged Networks", IEEE Std 802.1Q-2014, November 894 2014". 896 [EFM] IEEE, ""IEEE Standard for Ethernet (Clause 57 for 897 Operations, Administration, and Maintenance)", IEEE Std 898 802.3-2018, June 2018". 900 [I-D.ietf-ippm-ioam-data] 901 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 902 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 903 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 904 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 905 ietf-ippm-ioam-data-09 (work in progress), March 2020. 907 [I-D.ietf-sfc-ioam-nsh] 908 Brockners, F. and S. Bhandari, "Network Service Header 909 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 910 ietf-sfc-ioam-nsh-03 (work in progress), March 2020. 912 [I-D.ietf-sfc-proof-of-transit] 913 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 914 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 915 transit-04 (work in progress), November 2019. 917 [I-D.penno-sfc-trace] 918 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 919 "Services Function Chaining Traceroute", draft-penno-sfc- 920 trace-03 (work in progress), September 2015. 922 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 923 RFC 792, DOI 10.17487/RFC0792, September 1981, 924 . 926 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 927 "Framework for IP Performance Metrics", RFC 2330, 928 DOI 10.17487/RFC2330, May 1998, 929 . 931 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 932 Metric for IP Performance Metrics (IPPM)", RFC 3393, 933 DOI 10.17487/RFC3393, November 2002, 934 . 936 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 937 Control Message Protocol (ICMPv6) for the Internet 938 Protocol Version 6 (IPv6) Specification", STD 89, 939 RFC 4443, DOI 10.17487/RFC4443, March 2006, 940 . 942 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 943 Zekauskas, "A One-way Active Measurement Protocol 944 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 945 . 947 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 948 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 949 RFC 5357, DOI 10.17487/RFC5357, October 2008, 950 . 952 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 953 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 954 . 956 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 957 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 958 DOI 10.17487/RFC5881, June 2010, 959 . 961 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 962 "Bidirectional Forwarding Detection (BFD) for MPLS Label 963 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 964 June 2010, . 966 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 967 and A. Bierman, Ed., "Network Configuration Protocol 968 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 969 . 971 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 972 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 973 Acronym in the IETF", BCP 161, RFC 6291, 974 DOI 10.17487/RFC6291, June 2011, 975 . 977 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 978 Measurement for MPLS Networks", RFC 6374, 979 DOI 10.17487/RFC6374, September 2011, 980 . 982 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 983 Service Function Chaining", RFC 7498, 984 DOI 10.17487/RFC7498, April 2015, 985 . 987 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 988 Chaining (SFC) Architecture", RFC 7665, 989 DOI 10.17487/RFC7665, October 2015, 990 . 992 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 993 Ed., "A One-Way Delay Metric for IP Performance Metrics 994 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 995 2016, . 997 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 998 Ed., "A One-Way Loss Metric for IP Performance Metrics 999 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1000 2016, . 1002 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 1003 Pallagatti, "Seamless Bidirectional Forwarding Detection 1004 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 1005 . 1007 [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless 1008 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, 1009 and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, 1010 . 1012 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1013 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1014 Switched (MPLS) Data-Plane Failures", RFC 8029, 1015 DOI 10.17487/RFC8029, March 2017, 1016 . 1018 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1019 "Network Service Header (NSH)", RFC 8300, 1020 DOI 10.17487/RFC8300, January 2018, 1021 . 1023 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1024 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1025 DOI 10.17487/RFC8459, September 2018, 1026 . 1028 [Y.1731] ITU-T, "OAM Functions and mechanisms for Ethernet based 1029 networks", 1030 . 1032 Authors' Addresses 1034 Sam K. Aldrin 1035 Google 1037 Email: aldrin.ietf@gmail.com 1039 Carlos Pignataro (editor) 1040 Cisco Systems, Inc. 1042 Email: cpignata@cisco.com 1044 Nagendra Kumar (editor) 1045 Cisco Systems, Inc. 1047 Email: naikumar@cisco.com 1049 Ram Krishnan 1050 VMware 1052 Email: ramkri123@gmail.com 1054 Anoop Ghanwani 1055 Dell 1057 Email: anoop@alumni.duke.edu