idnits 2.17.1 draft-ietf-sfc-oam-framework-03.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 (September 7, 2017) is 2416 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8029' is defined on line 744, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-20 == Outdated reference: A later version (-05) exists of draft-brockners-proof-of-transit-03 Summary: 1 error (**), 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: March 11, 2018 N. Kumar, Ed. 6 Cisco 7 N. Akiya 8 Big Switch Networks 9 R. Krishnan 10 A. Ghanwani 11 Dell 12 September 7, 2017 14 Service Function Chaining (SFC) 15 Operation, Administration and Maintenance (OAM) Framework 16 draft-ietf-sfc-oam-framework-03 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 March 11, 2018. 47 Copyright Notice 49 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . 8 77 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 9 78 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 9 79 4.4. Performance Measurement Function . . . . . . . . . . . . 10 80 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 10 82 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 11 83 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . 13 91 6.4.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . 14 92 6.4.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . 14 93 6.5. Security Considerations . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 15 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. TBD - details will be provided in a 289 later revision. 291 3.2. Service Function Chain Component 293 3.2.1. Service Function Chain Availability 295 Verifying an SFC is a complicated process as the SFC could be 296 comprised of varying SF's. Thus, SFC requires the OAM layer to 297 perform validation and verification of SF's within an SFP, as well as 298 connectivity and fault isolation. 300 In order to perform service connectivity verification of an SFC, the 301 OAM could be initiated from any SFC aware network devices for end-to- 302 end paths or partial path terminating on a specific SF within the 303 SFC. The goal of this OAM function is to ensure the SF's chained 304 together has connectivity as it is intended to when SFC was 305 established. Necessary return code should be defined to be sent back 306 in the response to OAM packet, in order to qualify the verification. 308 When ECMP is in use at the service layer for any given SFC, there 309 must be the ability to discover and traverse all available paths. 311 TBD - further details will be provided in a later revision. 313 3.2.2. Service Function Chain Performance Measurement 315 Any SFC-aware network device must have the ability to perform loss 316 and delay measurements over the service function chain as a unit 317 (i.e. end-to-end) or to a specific segment of service function 318 through the SFC. 320 3.3. Classifier Component 322 A classifier maintains the classification rules that maps a flow to a 323 specific SFC. It is vital that the classifier is correctly 324 configured with updated classification rules and functioning 325 accordingly. The SFC OAM must be able to validate the classification 326 rules by assessing whether a flow is appropriately mapped to the 327 relevant SFC. Sample OAM packets can be presented to the classifiers 328 to assess the behavior with regards to a given classification entry. 330 4. SFC OAM Functions 332 Section 3 describes SFC OAM operations that is required on each SFC 333 component. This section explores the same from the OAM functionality 334 point of view, which many will be applicable to multiple SFC 335 components. 337 Various SFC OAM requirements listed in Section 3, provides the need 338 for various OAM functions at different layers. Many of the OAM 339 functions at different layers are already defined and in existence. 340 In order to apply such OAM functions at service layer, they have to 341 be enhanced to operate a single SF/SFF to multiple SFs/SFFs in an SFC 342 and also in multiple SFCs. 344 4.1. Connectivity Functions 346 Connectivity is mainly an on-demand function to verify that the 347 connectivity exists between network elements and the availability 348 exists to service functions. Ping is a common tool used to perform 349 this function. OAM messages SHOULD be encapsulated with necessary 350 SFC header and with OAM markings when testing the service function 351 chain component. OAM messages MAY be encapsulated with necessary SFC 352 header and with OAM markings when testing the service function 353 component. Some of the OAM functions performed by connectivity 354 functions are as follows: 356 o Verify the Path MTU from a source to the destination SF or through 357 the SFC. This requires the ability for OAM packet to take 358 variable length packet size. 360 o Verify the packet re-ordering and corruption. 362 o Verify the policy of an SFC or SF using OAM packet. 364 o Verification and validating forwarding paths. 366 o Proactively test alternate or protected paths to ensure 367 reliability of network configurations. 369 4.2. Continuity Functions 371 Continuity is a model where OAM messages are sent periodically to 372 validate or verify the reachability to a given SF or through a given 373 SFC. This allows monitor network device to quickly detect failures 374 like link failures, network failures, service function outages or 375 service function chain outages. BFD is one such function which helps 376 in detecting failures quickly. OAM functions supported by continuity 377 check are as follows: 379 o Ability to provision continuity check to a given SF or through a 380 given SFC. 382 o Notifying the failure upon failure detection for other OAM 383 functions to take appropriate action. 385 4.3. Trace Functions 387 Tracing is an important OAM function that allows the operation to 388 trigger an action (e.g., response generation) from every transit 389 device (e.g., SFF, SF, SFC Proxy etc) on the tested layer. This 390 function is typically useful to gather information from every transit 391 devices or to isolate the failure point towards an SF or through an 392 SFC. Some of the OAM functions supported by trace functions are: 394 o Ability to trigger action from every transit device on the tested 395 layer towards an SF or through an SFC, using TTL or other means. 397 o Ability to trigger every transit device to generate response with 398 OAM code(s) on the tested layer towards an SF or through an SFC, 399 using TTL or other means. 401 o Ability to discover and traverse ECMP paths within an SFC. 403 o Ability to skip un-supported SFs while tracing SFs in an SFC. 405 4.4. Performance Measurement Function 407 Performance management functions involve measuring of packet loss, 408 delay, delay variance, etc. These measurements could be measured 409 pro-actively and on-demand. 411 SFC OAM framework should provide the ability to perform packet loss 412 for an SFC. Measuring packet loss is very important function. Using 413 on-demand function, the packet loss could be measured using 414 statistical means. Using OAM packets, the approximation of packet 415 loss for a given SFC could be measured. 417 Delay within an SFC could be measured from the time it takes for a 418 packet to traverse the SFC from ingress SFC node to egress SFF. As 419 the SFCs are generally unidirectional in nature, measurement of one- 420 way delay [RFC7679] is important. In order to measure one-way delay, 421 time synchronization must be supported by means of NTP, PTP, GPS, 422 etc. 424 One-way delay variation [RFC3393] could also be measured by sending 425 OAM packets and measuring the jitter between the packets passing 426 through an SFC. 428 Some of the OAM functions supported by the performance measurement 429 functions are: 431 o Ability to measure the packet processing delay induced by a 432 service function or the one-way delay to traverse a service 433 function path along an SFC. 435 o Ability to measure the packet loss [RFC7680] within a service 436 function or a service function path bound to a given SFC. 438 5. Gap Analysis 440 This section identifies various OAM functions available at different 441 levels. It also identifies various gaps, if not all, existing within 442 the existing toolset, to perform OAM function required for SFC. 444 5.1. Existing OAM Functions 446 There are various OAM tool sets available to perform OAM functions 447 within various layers. These OAM functions could validate some of 448 the underlay and overlay networks. Tools like ping and trace are in 449 existence to perform connectivity check and tracing intermediate hops 450 in a network. These tools support different network types like IP, 451 MPLS, TRILL etc. There is also an effort to extend the tool set to 452 provide connectivity and continuity checks within overlay networks. 454 BFD is another tool which helps in detecting data forwarding 455 failures. The following table is not exhaustive. 457 +----------------+--------------+-------------+--------+------------+ 458 | Layer | Connectivity | Continuity | Trace | Performance| 459 +----------------+--------------+-------------+--------+------------+ 460 | Underlay N/w | Ping | E-OAM, BFD | Trace | IPPM, MPLS | 461 +----------------+--------------+-------------+--------+------------+ 462 | Overlay N/w | Ping | BFD, NVo3 | Trace | IPPM | 463 +----------------+--------------+-------------+--------+------------+ 464 | SF | None + None + None + None | 465 +----------------+--------------+-------------+--------+------------+ 466 | SFC | None + None + None + None | 467 +----------------+--------------+-------------+--------+------------+ 468 Table 3: OAM Tool GAP Analysis 470 +----------------+--------------+-------------+--------+------------+ 471 | Layer |Configuration |Orchestration|Topology|Notification| 472 +----------------+--------------+-------------+--------+------------+ 473 | Underlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog| 474 +----------------+--------------+-------------+--------+------------+ 475 | Overlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog| 476 +----------------+--------------+-------------+--------+------------+ 477 | SF |CLI, Netconf + CLI + None + None | 478 +----------------+--------------+-------------+--------+------------+ 479 | SFC |CLI, Netconf + CLI + None + None | 480 +----------------+--------------+-------------+--------+------------+ 481 Table 4: OAM Tool GAP Analysis (contd.) 483 5.2. Missing OAM Functions 485 As shown in Table 3, OAM functions for SFC are not standardized yet. 486 Hence, there are no standard based tools available to verify SF and 487 SFC. 489 5.3. Required OAM Functions 491 Primary OAM functions exist for underlying layers. Tools like ping, 492 trace, BFD, etc., exist in order to perform these OAM functions. 493 Configuration, orchestration and manageability of SF and SFC could be 494 performed using CLI, NETCONF, etc. 496 As depicted in Table 3 and 4, for configuration, manageability and 497 orchestration, providing data and information models for SFC is very 498 much needed. With virtualized SF and SFC, manageability of these 499 functions has to be done programmatically. 501 6. SFC OAM Model 503 This section describes the operational aspects of SFC OAM at the 504 Service layer to perform the SFC OAM function defined in Section 4 505 and analyze the applicability of various existing OAM toolsets in the 506 service layer. 508 6.1. SFC OAM Packet Marker 510 SFC OAM function described in Section 4 performed at the service 511 layer or overlay network layer must mark the packet as OAM packet so 512 that relevant nodes can differentiate an OAM packet from data 513 packets. The base header defined in Section 3.2 of 514 [I-D.ietf-sfc-nsh] assigns a bit to indicate OAM packets. When NSH 515 encapsulation is used at the service layer, the O bit must be set to 516 differentiate the OAM packet. Any other overlay encapsulations used 517 in future must have a way to mark the packet as OAM packet. 519 6.2. OAM Packet Processing and Forwarding Semantic 521 Upon receiving OAM packet, an SFC-aware SFs may choose to discard the 522 packet if it does not support OAM functionality or if the local 523 policy prevent it from processing OAM packet. When SF supports OAM 524 functionality, it is desired to process the packet and respond back 525 accordingly that helps with end-to-end verification. To avoid 526 hitting any performance impact, SFC-aware SFs can rate limit the 527 number of OAM packets processed. 529 Service Function Forwarder (SFF) may choose not to forward the OAM 530 packet to an SF if the SF does not support OAM function or if the 531 policy does not allow to forward OAM packet to an SF. SFF may choose 532 to skip the SF, modify the header and forward to next SFC node in the 533 chain. Although, skipping an SF might have implication on some OAM 534 function (e.g., delay measurement may not be accurate). How SFF 535 detects if the connected SF supports or allowed to process OAM packet 536 is outside the scope of this document. It could be a configuration 537 parameter instructed by the controller or can be a dynamic 538 negotiation between SF and SFF. 540 If the SFF receiving the OAM packet bound to a given SFC is the last 541 SFF in the chain, it must send a relevant response to the initiator 542 of the OAM packet. Depending on the type of OAM solution and tool 543 set used, the response could be a simple response (ICMP reply or BFD 544 reply packet) or could include additional data from the received OAM 545 packet (like stats data consolidated along the path). The proposed 546 solution should detail it further. 548 Any SFC-aware node that initiates OAM packet must set the OAM marker 549 in the overlay encapsulation. 551 6.3. OAM Function Types 553 As described in Section 4, there are different OAM functions that may 554 require different OAM solutions. While the presence of OAM marker in 555 the overlay header (e.g., O bit in the NSH header) indicates it as 556 OAM packet, it is not sufficient to indicate what OAM function the 557 packet is intended for. The Next Protocol field in NSH header may be 558 used to indicate what OAM function is it intended to or what toolset 559 is used. 561 6.4. OAM Toolset applicability 563 As described in Section 5.1, there are different tool sets available 564 to perform OAM functions at different layers. This section describes 565 the applicability of some of the available toolsets in the service 566 layer. 568 6.4.1. ICMP Applicability 570 [RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 571 network respectively. It explains how ICMP messages can be used to 572 test the network reachability between different end points and 573 perform basic network diagnostics. 575 ICMP could be leveraged for basic OAM functions like SF availability 576 or SFC availability. The Initiator can generate ICMP echo request 577 message and control the service layer encapsulation header to get the 578 response from relevant node. For example, a classifier initiating 579 OAM can generate ICMP echo request message, can set the TTL field in 580 NSH header to 255 to get the response from last SFF and thereby test 581 the SFC availability. Alternately, the initiator can set the TTL to 582 other value to get the response from specific SFs and there by test 583 partial SFC availability. Alternately, the initiator could send OAM 584 packets with sequentially incrementing the TTL in NSH header to trace 585 the SFP. 587 It could be observed that ICMP at its current stage may not be able 588 to perform all required SFC OAM functions, but as explained above, it 589 can be used for basic OAM functions. 591 6.4.2. Seamless BFD Applicability 593 [RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism 594 for fast failure detection. [RFC5881] and [RFC5884] defines the 595 applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] 596 defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. 597 [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. 599 S-BFD could be leveraged to perform SF or SFC availability. An 600 initiator could generate BFD control packet and set the "Your 601 Discriminator" value as last SFF in the control packet. Upon 602 receiving the control packet, last SFF will reply back with relevant 603 DIAG code. We could also use the TTL field in the NSH header to 604 perform partial SFC availability. For example, the initiator can set 605 the "Your Discriminator" value to the SF that is intended to be 606 tested and set the TTL field in NSH header in a way that it will be 607 expired on the relevant SF. How the initiator gets the Discriminator 608 value of the SF is outside the scope of this document. 610 6.4.3. In-Situ OAM 612 [I-D.brockners-proof-of-transit] defines a mechanism to perform proof 613 of transit to securely verify if a packet traversed the relevant path 614 or chain. While the mechanism is defined inband (i.e, it will be 615 included in data packets), it can be used to perform various SFC OAM 616 functions as well. 618 In-Situ OAM could be used with O bit set and perform SF availability, 619 SFC availability of performance measurement. 621 6.4.4. SFC Traceroute 623 [I-D.penno-sfc-trace] defines a protocol that checks for path 624 liveliness and trace the service hops in any SFP. Section 3 of 625 [I-D.penno-sfc-trace] defines the SFC trace packet format while 626 section 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF 627 and SFF respectively. 629 An initiator can control the SIL in SFC trace packet to perform SF 630 and SFC availability test. 632 6.5. Security Considerations 634 SFC and SF OAM must provide mechanisms for: 636 o Preventing usage of OAM channel for DDOS attacks. 638 o OAM packets meant for a given SFC should not get leaked beyond 639 that SFC. 641 o Prevent OAM packets to leak the information of an SFC beyond its 642 administrative domain. 644 6.6. IANA Considerations 646 No action is required by IANA for this document. 648 6.7. Acknowledgements 650 We would like to thank Mohamed Boucadair for his review and comments. 652 7. References 654 7.1. Normative References 656 [I-D.ietf-sfc-nsh] 657 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 658 Header (NSH)", draft-ietf-sfc-nsh-20 (work in progress), 659 September 2017. 661 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 662 RFC 792, DOI 10.17487/RFC0792, September 1981, 663 . 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, 667 DOI 10.17487/RFC2119, March 1997, 668 . 670 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 671 Control Message Protocol (ICMPv6) for the Internet 672 Protocol Version 6 (IPv6) Specification", STD 89, 673 RFC 4443, DOI 10.17487/RFC4443, March 2006, 674 . 676 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 677 Service Function Chaining", RFC 7498, 678 DOI 10.17487/RFC7498, April 2015, 679 . 681 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 682 Chaining (SFC) Architecture", RFC 7665, 683 DOI 10.17487/RFC7665, October 2015, 684 . 686 7.2. Informative References 688 [I-D.brockners-proof-of-transit] 689 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 690 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 691 of Transit", draft-brockners-proof-of-transit-03 (work in 692 progress), March 2017. 694 [I-D.penno-sfc-trace] 695 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 696 "Services Function Chaining Traceroute", draft-penno-sfc- 697 trace-03 (work in progress), September 2015. 699 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 700 Metric for IP Performance Metrics (IPPM)", RFC 3393, 701 DOI 10.17487/RFC3393, November 2002, 702 . 704 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 705 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 706 . 708 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 709 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 710 DOI 10.17487/RFC5881, June 2010, 711 . 713 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 714 "Bidirectional Forwarding Detection (BFD) for MPLS Label 715 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 716 June 2010, . 718 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 719 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 720 Acronym in the IETF", BCP 161, RFC 6291, 721 DOI 10.17487/RFC6291, June 2011, 722 . 724 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 725 Ed., "A One-Way Delay Metric for IP Performance Metrics 726 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 727 2016, . 729 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 730 Ed., "A One-Way Loss Metric for IP Performance Metrics 731 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 732 2016, . 734 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 735 Pallagatti, "Seamless Bidirectional Forwarding Detection 736 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 737 . 739 [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless 740 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, 741 and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, 742 . 744 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 745 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 746 Switched (MPLS) Data-Plane Failures", RFC 8029, 747 DOI 10.17487/RFC8029, March 2017, 748 . 750 Authors' Addresses 752 Sam K. Aldrin 753 Google 755 Email: aldrin.ietf@gmail.com 757 Carlos Pignataro (editor) 758 Cisco Systems, Inc. 760 Email: cpignata@cisco.com 762 Nagendra Kumar (editor) 763 Cisco Systems, Inc. 765 Email: naikumar@cisco.com 767 Nobo Akiya 768 Big Switch Networks 770 Email: nobo.akiya.dev@gmail.com 772 Ram Krishnan 773 Dell 775 Email: ramkri123@gmail.com 776 Anoop Ghanwani 777 Dell 779 Email: anoop@alumni.duke.edu