idnits 2.17.1 draft-ietf-sfc-oam-framework-06.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 3 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 (March 25, 2019) is 1853 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8029' is defined on line 754, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-sfc-proof-of-transit-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Aldrin 3 Internet-Draft Google 4 Intended status: Informational C. Pignataro, Ed. 5 Expires: September 26, 2019 N. Kumar, Ed. 6 Cisco 7 N. Akiya 8 Big Switch Networks 9 R. Krishnan 10 A. Ghanwani 11 Dell 12 March 25, 2019 14 Service Function Chaining (SFC) 15 Operation, Administration and Maintenance (OAM) Framework 16 draft-ietf-sfc-oam-framework-06 18 Abstract 20 This document provides a reference framework for Operations, 21 Administration and Maintenance (OAM) for Service Function Chaining 22 (SFC). 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 26, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 3 66 2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 4 67 3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Service Function Component . . . . . . . . . . . . . . . 6 69 3.1.1. Service Function Availability . . . . . . . . . . . . 6 70 3.1.2. Service Function Performance Measurement . . . . . . 7 71 3.2. Service Function Chain Component . . . . . . . . . . . . 7 72 3.2.1. Service Function Chain Availability . . . . . . . . . 7 73 3.2.2. Service Function Chain Performance Measurement . . . 8 74 3.3. Classifier Component . . . . . . . . . . . . . . . . . . 8 75 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 8 76 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 9 77 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 9 78 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 9 79 4.4. Performance Measurement Function . . . . . . . . . . . . 10 80 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 11 82 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 12 83 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 12 84 6. SFC OAM Model . . . . . . . . . . . . . . . . . . . . . . . . 12 85 6.1. SFC OAM Packet Marker . . . . . . . . . . . . . . . . . . 12 86 6.2. OAM Packet Processing and Forwarding Semantic . . . . . . 12 87 6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 13 88 6.4. OAM Toolset applicability . . . . . . . . . . . . . . . . 13 89 6.4.1. ICMP Applicability . . . . . . . . . . . . . . . . . 13 90 6.4.2. Seamless BFD Applicability . . . . . . . . . . . . . 14 91 6.4.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . 14 92 6.4.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . 14 93 6.5. Security Considerations . . . . . . . . . . . . . . . . . 15 94 6.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 95 6.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 15 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 98 7.2. Informative References . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 101 1. Introduction 103 Service Function Chaining (SFC) enables the creation of composite 104 services that consist of an ordered set of Service Functions (SF) 105 that are to be applied to packets and/or frames selected as a result 106 of classification [RFC7665]. Service Function Chaining is a concept 107 that provides for more than just the application of an ordered set of 108 SFs to selected traffic; rather, it describes a method for deploying 109 SFs in a way that enables dynamic ordering and topological 110 independence of those SFs as well as the exchange of metadata between 111 participating entities. The foundations of SFC are described in the 112 following documents: 114 o SFC Problem Statement [RFC7498] 116 o SFC Architecture [RFC7665] 118 The reader is assumed to be familiar with the material in these 119 documents. 121 This document provides a reference framework for Operations, 122 Administration and Maintenance (OAM, [RFC6291]) of SFC. 123 Specifically, this document provides: 125 o In Section 2, an SFC layering model; 127 o In Section 3, aspects monitored by SFC OAM; 129 o In Section 4, functional requirements for SFC OAM; 131 o In Section 5, a gap analysis for SFC OAM. 133 1.1. Document Scope 135 The focus of this document is to provide an architectural framework 136 for SFC OAM, particularly focused on the aspect of the Operations 137 component within OAM. Actual solutions and mechanisms are outside 138 the scope of this document. 140 2. SFC Layering Model 142 Multiple layers come into play for implementing the SFC. These 143 include the service layer and the underlying layers (Network, Link 144 etc) 146 o The service layer in Figure 1, consists of SFC data plane elements 147 that includes classifiers, Service Functions (SF), Service 148 Function Forwarders (SFF), SFC Proxy. This layer uses the overlay 149 network for ensuring connectivity between SFC data plane elements. 151 o The overlay network layer in Figure 1, leverages various overlay 152 network technologies interconnecting SFC data plane elements and 153 allows establishing service function paths (SFPs). This layer is 154 mostly transparent to the SFC data plane elements. 156 o The underlay network layer in Figure 1, is dictated by the 157 networking technology deployed within a network (e.g., IP, MPLS) 159 o The link layer in Figure 1, is dependent upon the physical 160 technology used. Ethernet is a popular choice for this layer, but 161 other alternatives are deployed (e.g. POS, DWDM etc...). The 162 same or distinct link layer technologies may be used in each leg 163 shown in figure 1. 165 o----------------------Service Layer----------------------o 167 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 168 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 169 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 170 +------+ 171 o------VM1------o o--VM2--o o--VM3--o 173 o-----------------o-------------------o---------------o Overlay network 175 o-----------------o-----------------------------------o Underlay network 177 o--------o--------o--------o--------o--------o--------o Link 179 Figure 1: SFC Layering Example 181 While Figure 1 depicts a sample example where SFs are enabled as 182 virtual entities, the SFC architecture does not make any assumptions 183 on how SFC data plane elements are deployed. The SFC architecture is 184 flexible to accomodate physical or virtual entity deployment. SFC 185 OAM adheres to this flexibility and accordingly it is applicable 186 whether SFC data plane elements are deployed directly on physical 187 hardware, as one or more Virtual Machines, or any combination 188 thereof. 190 3. SFC OAM Components 192 The SFC operates at the service layer. For the purpose of defining 193 the OAM framework, the service layer is broken up into three distinct 194 components. 196 1. SF component: OAM solutions for this component include testing 197 the service functions from any SFC-aware network devices (i.e. 198 classifiers, controllers, other service nodes). 200 2. SFC component: OAM solutions for this component include testing 201 the service function chains and the SFPs, validate the 202 correlation between a Service Function Chain and the actual 203 forwarding path followed by a packet matching that SFC, etc. 205 3. Classifier component: OAM solutions for this component include 206 testing the validity of the classification rules and detecting 207 any incoherence among the rules installed in different 208 classifiers. 210 Below figure illustrates an example where OAM for the three defined 211 components are used within the SFC environment. 213 +-Classifier +-Service Function Chain OAM 214 | OAM | 215 | | ______________________________________________ 216 | \ /\ Service Function Chain \ 217 | \ / \ +---+ +---+ +-----+ +---+ \ 218 | \ / \ |SF1| |SF2| |Proxy|--|SF3| \ 219 | +------+ \/ \ +---+ +---+ +-----+ +---+ \ 220 +----> | |...(+-> ) | | | ) 221 |Classi| \ / +-----+ +-----+ +-----+ / 222 |fier | \ / | SFF1|----| SFF2|----| SFF3| / 223 | | \ / +--^--+ +--^--+ +-----+ / 224 +----|-+ \/____________|________________________________/ 225 | | 226 +----------SF_OAM------+ 227 +---+ +---+ 228 +SF_OAM>|SF3| |SF5| 229 | +-^-+ +-^-+ 230 +------|---+ | | 231 |Controller| +-SF_OAM+ 232 +----------+ 233 Service Function OAM (SF_OAM) 235 Figure 2: SFC OAM for Three Components 237 It is expected that multiple SFC OAM solutions will be defined, many 238 targeting one specific component of the service layer. However, it 239 is critical that SFC OAM solutions together provide the coverage of 240 all three SFC OAM components: the service function component, the 241 service function chain component and the classifier component. 243 3.1. Service Function Component 245 3.1.1. Service Function Availability 247 One SFC OAM requirement for the service function component is to 248 allow an SFC-aware network device to check the availability to a 249 specific service function, located on the same or different network 250 devices. Service function availability is an aspect which raises an 251 interesting question. How to determine that a service function is 252 available?. On one end of the spectrum, one might argue that a 253 service function is sufficiently available if the service node 254 (physical or virtual) hosting the service function is available and 255 is functional. On the other end of the spectrum, one might argue 256 that the service function availability can only be concluded if the 257 packet, after passing through the service function, was examined and 258 verified that the packet got expected service applied. 260 The former approach will likely not provide sufficient confidence to 261 the actual service function availability, i.e. a service node and a 262 service function are two different entities. The latter approach is 263 capable of providing an extensive verification, but comes with a 264 cost. Some service functions make direct modifications to packets, 265 while other service functions do not make any modifications to 266 packets. Additionally, purpose of some service functions is to, 267 conditionally, drop packets intentionally. In such case, packets 268 will not be coming out from the service function. The fact is that 269 there are many flavors of service functions available, and many more 270 flavors of service functions will likely be introduced in future. 271 Even a given service function may introduce a new functionality 272 within a service function (e.g., a new signature in a firewall). The 273 cost of this approach is that verifier functions will need to be 274 continuously modified to "keep up" with new services coming out: lack 275 of extendibility. 277 This framework document provides a RECOMMENDED architectural model 278 where generalized approach is taken to verify that a service function 279 is sufficiently available. More specifics on the mechanism to 280 characterize SF-specific OAM to validate the service offering is 281 outside the scope of this document. Those mechanism are 282 implementation and deployment specific. 284 3.1.2. Service Function Performance Measurement 286 Second SFC OAM requirement for the service function component is to 287 allow an SFC aware network device to check the loss and delay induced 288 by a specific service function. The performance can be a passive 289 measurement by using live traffic or can be active measurement by 290 using synthetic probe packets. 292 On one hand, the performance of any specific service function can be 293 measured by measuring the loss and delay metric of the traffic from 294 service node to the respective service function, while on the other 295 hand, the performance can be measured by leveraging the loss and 296 delay metrics from the respective service functions. The latter 297 requires service function involvement to perform the measurement 298 while the former does not. 300 3.2. Service Function Chain Component 302 3.2.1. Service Function Chain Availability 304 Verifying an SFC is a complicated process as the SFC could be 305 comprised of varying SF's. Thus, SFC requires the OAM layer to 306 perform validation and verification of SF's within an SFP, as well as 307 connectivity and fault isolation. 309 In order to perform service connectivity verification of an SFC, the 310 OAM could be initiated from any SFC aware network devices for end-to- 311 end paths or partial path terminating on a specific SF within the 312 SFC. The goal of this OAM function is to ensure the SF's chained 313 together has connectivity as it is intended to when SFC was 314 established. Necessary return code should be defined to be sent back 315 in the response to OAM packet, in order to qualify the verification. 317 When ECMP is in use at the service layer for any given SFC, there 318 must be the ability to discover and traverse all available paths. 320 Detailed explanation on the mechanism is outside the scope of this 321 document and will be expected to be included in the actual solution 322 document. 324 3.2.2. Service Function Chain Performance Measurement 326 Any SFC-aware network device must have the ability to perform loss 327 and delay measurements over the service function chain as a unit 328 (i.e. end-to-end) or to a specific segment of service function 329 through the SFC. 331 3.3. Classifier Component 333 A classifier maintains the classification rules that maps a flow to a 334 specific SFC. It is vital that the classifier is correctly 335 configured with updated classification rules and functioning 336 accordingly. The SFC OAM must be able to validate the classification 337 rules by assessing whether a flow is appropriately mapped to the 338 relevant SFC. Sample OAM packets can be presented to the classifiers 339 to assess the behavior with regards to a given classification entry. 341 4. SFC OAM Functions 343 Section 3 describes SFC OAM operations that is required on each SFC 344 component. This section explores the same from the OAM functionality 345 point of view, which many will be applicable to multiple SFC 346 components. 348 Various SFC OAM requirements listed in Section 3, provides the need 349 for various OAM functions at different layers. Many of the OAM 350 functions at different layers are already defined and in existence. 351 In order to apply such OAM functions at service layer, they have to 352 be enhanced to operate a single SF/SFF to multiple SFs/SFFs in an SFC 353 and also in multiple SFCs. 355 4.1. Connectivity Functions 357 Connectivity is mainly an on-demand function to verify that the 358 connectivity exists between network elements and the availability 359 exists to service functions. Ping is a common tool used to perform 360 this function. OAM messages SHOULD be encapsulated with necessary 361 SFC header and with OAM markings when testing the service function 362 chain component. OAM messages MAY be encapsulated with necessary SFC 363 header and with OAM markings when testing the service function 364 component. Some of the OAM functions performed by connectivity 365 functions are as follows: 367 o Verify the Path MTU from a source to the destination SF or through 368 the SFC. This requires the ability for OAM packet to take 369 variable length packet size. 371 o Verify the packet re-ordering and corruption. 373 o Verify the policy of an SFC or SF using OAM packet. 375 o Verification and validating forwarding paths. 377 o Proactively test alternate or protected paths to ensure 378 reliability of network configurations. 380 4.2. Continuity Functions 382 Continuity is a model where OAM messages are sent periodically to 383 validate or verify the reachability to a given SF or through a given 384 SFC. This allows monitor network device to quickly detect failures 385 like link failures, network failures, service function outages or 386 service function chain outages. BFD is one such function which helps 387 in detecting failures quickly. OAM functions supported by continuity 388 check are as follows: 390 o Ability to provision continuity check to a given SF or through a 391 given SFC. 393 o Notifying the failure upon failure detection for other OAM 394 functions to take appropriate action. 396 4.3. Trace Functions 398 Tracing is an important OAM function that allows the operation to 399 trigger an action (e.g., response generation) from every transit 400 device (e.g., SFF, SF, SFC Proxy etc) on the tested layer. This 401 function is typically useful to gather information from every transit 402 devices or to isolate the failure point towards an SF or through an 403 SFC. Some of the OAM functions supported by trace functions are: 405 o Ability to trigger action from every transit device on the tested 406 layer towards an SF or through an SFC, using TTL or other means. 408 o Ability to trigger every transit device to generate response with 409 OAM code(s) on the tested layer towards an SF or through an SFC, 410 using TTL or other means. 412 o Ability to discover and traverse ECMP paths within an SFC. 414 o Ability to skip un-supported SFs while tracing SFs in an SFC. 416 4.4. Performance Measurement Function 418 Performance management functions involve measuring of packet loss, 419 delay, delay variance, etc. These measurements could be measured 420 pro-actively and on-demand. 422 SFC OAM framework should provide the ability to perform packet loss 423 for an SFC. Measuring packet loss is very important function. Using 424 on-demand function, the packet loss could be measured using 425 statistical means. Using OAM packets, the approximation of packet 426 loss for a given SFC could be measured. 428 Delay within an SFC could be measured from the time it takes for a 429 packet to traverse the SFC from ingress SFC node to egress SFF. As 430 the SFCs are generally unidirectional in nature, measurement of one- 431 way delay [RFC7679] is important. In order to measure one-way delay, 432 time synchronization must be supported by means of NTP, PTP, GPS, 433 etc. 435 One-way delay variation [RFC3393] could also be measured by sending 436 OAM packets and measuring the jitter between the packets passing 437 through an SFC. 439 Some of the OAM functions supported by the performance measurement 440 functions are: 442 o Ability to measure the packet processing delay induced by a 443 service function or the one-way delay to traverse a service 444 function path along an SFC. 446 o Ability to measure the packet loss [RFC7680] within a service 447 function or a service function path bound to a given SFC. 449 5. Gap Analysis 451 This section identifies various OAM functions available at different 452 levels. It also identifies various gaps, if not all, existing within 453 the existing toolset, to perform OAM function required for SFC. 455 5.1. Existing OAM Functions 457 There are various OAM tool sets available to perform OAM functions 458 within various layers. These OAM functions could validate some of 459 the underlay and overlay networks. Tools like ping and trace are in 460 existence to perform connectivity check and tracing intermediate hops 461 in a network. These tools support different network types like IP, 462 MPLS, TRILL etc. There is also an effort to extend the tool set to 463 provide connectivity and continuity checks within overlay networks. 464 BFD is another tool which helps in detecting data forwarding 465 failures. The following table is not exhaustive. 467 +----------------+--------------+-------------+--------+------------+ 468 | Layer | Connectivity | Continuity | Trace | Performance| 469 +----------------+--------------+-------------+--------+------------+ 470 | Underlay N/w | Ping | E-OAM, BFD | Trace | IPPM, MPLS | 471 +----------------+--------------+-------------+--------+------------+ 472 | Overlay N/w | Ping | BFD, NVo3 | Trace | IPPM | 473 +----------------+--------------+-------------+--------+------------+ 474 | SF | None + None + None + None | 475 +----------------+--------------+-------------+--------+------------+ 476 | SFC | None + None + None + None | 477 +----------------+--------------+-------------+--------+------------+ 478 Table 3: OAM Tool GAP Analysis 480 +----------------+--------------+-------------+--------+------------+ 481 | Layer |Configuration |Orchestration|Topology|Notification| 482 +----------------+--------------+-------------+--------+------------+ 483 | Underlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog| 484 +----------------+--------------+-------------+--------+------------+ 485 | Overlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog| 486 +----------------+--------------+-------------+--------+------------+ 487 | SF |CLI, Netconf + CLI + None + None | 488 +----------------+--------------+-------------+--------+------------+ 489 | SFC |CLI, Netconf + CLI + None + None | 490 +----------------+--------------+-------------+--------+------------+ 491 Table 4: OAM Tool GAP Analysis (contd.) 493 5.2. Missing OAM Functions 495 As shown in Table 3, OAM functions for SFC are not standardized yet. 496 Hence, there are no standard based tools available to verify SF and 497 SFC. 499 5.3. Required OAM Functions 501 Primary OAM functions exist for underlying layers. Tools like ping, 502 trace, BFD, etc., exist in order to perform these OAM functions. 503 Configuration, orchestration and manageability of SF and SFC could be 504 performed using CLI, NETCONF, etc. 506 As depicted in Table 3 and 4, for configuration, manageability and 507 orchestration, providing data and information models for SFC is very 508 much needed. With virtualized SF and SFC, manageability of these 509 functions has to be done programmatically. 511 6. SFC OAM Model 513 This section describes the operational aspects of SFC OAM at the 514 Service layer to perform the SFC OAM function defined in Section 4 515 and analyze the applicability of various existing OAM toolsets in the 516 service layer. 518 6.1. SFC OAM Packet Marker 520 SFC OAM function described in Section 4 performed at the service 521 layer or overlay network layer must mark the packet as OAM packet so 522 that relevant nodes can differentiate an OAM packet from data 523 packets. The base header defined in Section 2.2 of [RFC8300] assigns 524 a bit to indicate OAM packets. When NSH encapsulation is used at the 525 service layer, the O bit must be set to differentiate the OAM packet. 526 Any other overlay encapsulations used in future must have a way to 527 mark the packet as OAM packet. 529 6.2. OAM Packet Processing and Forwarding Semantic 531 Upon receiving OAM packet, an SFC-aware SFs may choose to discard the 532 packet if it does not support OAM functionality or if the local 533 policy prevent it from processing OAM packet. When SF supports OAM 534 functionality, it is desired to process the packet and respond back 535 accordingly that helps with end-to-end verification. To avoid 536 hitting any performance impact, SFC-aware SFs can rate limit the 537 number of OAM packets processed. 539 Service Function Forwarder (SFF) may choose not to forward the OAM 540 packet to an SF if the SF does not support OAM function or if the 541 policy does not allow to forward OAM packet to an SF. SFF may choose 542 to skip the SF, modify the header and forward to next SFC node in the 543 chain. Although, skipping an SF might have implication on some OAM 544 function (e.g., delay measurement may not be accurate). How SFF 545 detects if the connected SF supports or allowed to process OAM packet 546 is outside the scope of this document. It could be a configuration 547 parameter instructed by the controller or can be a dynamic 548 negotiation between SF and SFF. 550 If the SFF receiving the OAM packet bound to a given SFC is the last 551 SFF in the chain, it must send a relevant response to the initiator 552 of the OAM packet. Depending on the type of OAM solution and tool 553 set used, the response could be a simple response (ICMP reply or BFD 554 reply packet) or could include additional data from the received OAM 555 packet (like stats data consolidated along the path). The proposed 556 solution should detail it further. 558 Any SFC-aware node that initiates OAM packet must set the OAM marker 559 in the overlay encapsulation. 561 6.3. OAM Function Types 563 As described in Section 4, there are different OAM functions that may 564 require different OAM solutions. While the presence of OAM marker in 565 the overlay header (e.g., O bit in the NSH header) indicates it as 566 OAM packet, it is not sufficient to indicate what OAM function the 567 packet is intended for. The Next Protocol field in NSH header may be 568 used to indicate what OAM function is it intended to or what toolset 569 is used. 571 6.4. OAM Toolset applicability 573 As described in Section 5.1, there are different tool sets available 574 to perform OAM functions at different layers. This section describes 575 the applicability of some of the available toolsets in the service 576 layer. 578 6.4.1. ICMP Applicability 580 [RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 581 network respectively. It explains how ICMP messages can be used to 582 test the network reachability between different end points and 583 perform basic network diagnostics. 585 ICMP could be leveraged for basic OAM functions like SF availability 586 or SFC availability. The Initiator can generate ICMP echo request 587 message and control the service layer encapsulation header to get the 588 response from relevant node. For example, a classifier initiating 589 OAM can generate ICMP echo request message, can set the TTL field in 590 NSH header to 255 to get the response from last SFF and thereby test 591 the SFC availability. Alternately, the initiator can set the TTL to 592 other value to get the response from specific SFs and there by test 593 partial SFC availability. Alternately, the initiator could send OAM 594 packets with sequentially incrementing the TTL in NSH header to trace 595 the SFP. 597 It could be observed that ICMP at its current stage may not be able 598 to perform all required SFC OAM functions, but as explained above, it 599 can be used for basic OAM functions. 601 6.4.2. Seamless BFD Applicability 603 [RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism 604 for fast failure detection. [RFC5881] and [RFC5884] defines the 605 applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] 606 defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. 607 [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. 609 S-BFD could be leveraged to perform SF or SFC availability. An 610 initiator could generate BFD control packet and set the "Your 611 Discriminator" value as last SFF in the control packet. Upon 612 receiving the control packet, last SFF will reply back with relevant 613 DIAG code. We could also use the TTL field in the NSH header to 614 perform partial SFC availability. For example, the initiator can set 615 the "Your Discriminator" value to the SF that is intended to be 616 tested and set the TTL field in NSH header in a way that it will be 617 expired on the relevant SF. How the initiator gets the Discriminator 618 value of the SF is outside the scope of this document. 620 6.4.3. In-Situ OAM 622 [I-D.ietf-sfc-proof-of-transit] defines a mechanism to perform proof 623 of transit to securely verify if a packet traversed the relevant path 624 or chain. While the mechanism is defined inband (i.e, it will be 625 included in data packets), it can be used to perform various SFC OAM 626 functions as well. 628 In-Situ OAM could be used with O bit set and perform SF availability, 629 SFC availability of performance measurement. 631 6.4.4. SFC Traceroute 633 [I-D.penno-sfc-trace] defines a protocol that checks for path 634 liveliness and trace the service hops in any SFP. Section 3 of 635 [I-D.penno-sfc-trace] defines the SFC trace packet format while 636 section 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF 637 and SFF respectively. 639 An initiator can control the SIL in SFC trace packet to perform SF 640 and SFC availability test. 642 6.5. Security Considerations 644 SFC and SF OAM must provide mechanisms for: 646 o Preventing usage of OAM channel for DDOS attacks. 648 o OAM packets meant for a given SFC should not get leaked beyond 649 that SFC. 651 o Prevent OAM packets to leak the information of an SFC beyond its 652 administrative domain. 654 6.6. IANA Considerations 656 No action is required by IANA for this document. 658 6.7. Acknowledgements 660 We would like to thank Mohamed Boucadair for his review and comments. 662 7. References 664 7.1. Normative References 666 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 667 RFC 792, DOI 10.17487/RFC0792, September 1981, 668 . 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, 672 DOI 10.17487/RFC2119, March 1997, 673 . 675 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 676 Control Message Protocol (ICMPv6) for the Internet 677 Protocol Version 6 (IPv6) Specification", STD 89, 678 RFC 4443, DOI 10.17487/RFC4443, March 2006, 679 . 681 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 682 Service Function Chaining", RFC 7498, 683 DOI 10.17487/RFC7498, April 2015, 684 . 686 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 687 Chaining (SFC) Architecture", RFC 7665, 688 DOI 10.17487/RFC7665, October 2015, 689 . 691 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 692 "Network Service Header (NSH)", RFC 8300, 693 DOI 10.17487/RFC8300, January 2018, 694 . 696 7.2. Informative References 698 [I-D.ietf-sfc-proof-of-transit] 699 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 700 Leddy, J., Youell, S., Mozes, D., Mizrahi, T., Aguado, A., 701 and D. Lopez, "Proof of Transit", draft-ietf-sfc-proof-of- 702 transit-02 (work in progress), March 2019. 704 [I-D.penno-sfc-trace] 705 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 706 "Services Function Chaining Traceroute", draft-penno-sfc- 707 trace-03 (work in progress), September 2015. 709 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 710 Metric for IP Performance Metrics (IPPM)", RFC 3393, 711 DOI 10.17487/RFC3393, November 2002, 712 . 714 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 715 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 716 . 718 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 719 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 720 DOI 10.17487/RFC5881, June 2010, 721 . 723 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 724 "Bidirectional Forwarding Detection (BFD) for MPLS Label 725 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 726 June 2010, . 728 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 729 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 730 Acronym in the IETF", BCP 161, RFC 6291, 731 DOI 10.17487/RFC6291, June 2011, 732 . 734 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 735 Ed., "A One-Way Delay Metric for IP Performance Metrics 736 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 737 2016, . 739 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 740 Ed., "A One-Way Loss Metric for IP Performance Metrics 741 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 742 2016, . 744 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 745 Pallagatti, "Seamless Bidirectional Forwarding Detection 746 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 747 . 749 [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless 750 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, 751 and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, 752 . 754 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 755 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 756 Switched (MPLS) Data-Plane Failures", RFC 8029, 757 DOI 10.17487/RFC8029, March 2017, 758 . 760 Authors' Addresses 762 Sam K. Aldrin 763 Google 765 Email: aldrin.ietf@gmail.com 767 Carlos Pignataro (editor) 768 Cisco Systems, Inc. 770 Email: cpignata@cisco.com 771 Nagendra Kumar (editor) 772 Cisco Systems, Inc. 774 Email: naikumar@cisco.com 776 Nobo Akiya 777 Big Switch Networks 779 Email: nobo.akiya.dev@gmail.com 781 Ram Krishnan 782 Dell 784 Email: ramkri123@gmail.com 786 Anoop Ghanwani 787 Dell 789 Email: anoop@alumni.duke.edu