idnits 2.17.1 draft-ietf-sfc-oam-framework-02.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 (July 3, 2017) is 2479 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8029' is defined on line 696, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-brockners-proof-of-transit-03 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-13 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: January 4, 2018 N. Kumar, Ed. 6 Cisco 7 N. Akiya 8 Big Switch Networks 9 R. Krishnan 10 A. Ghanwani 11 Dell 12 July 3, 2017 14 Service Function Chaining 15 Operation, Administration and Maintenance Framework 16 draft-ietf-sfc-oam-framework-02 18 Abstract 20 This document provides 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 http://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 January 4, 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 (http://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 . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Service Function Component . . . . . . . . . . . . . . . 5 69 3.1.1. Service Function Availability . . . . . . . . . . . . 5 70 3.1.2. Service Function Performance Measurement . . . . . . 6 71 3.2. Service Function Chain Component . . . . . . . . . . . . 6 72 3.2.1. Service Function Chain Availability . . . . . . . . . 6 73 3.2.2. Service Function Chain Performance Measurement . . . 7 74 3.3. Classifier Component . . . . . . . . . . . . . . . . . . 7 75 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 7 77 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 8 78 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 8 79 4.4. Performance Measurement Function . . . . . . . . . . . . 9 80 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 9 82 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 10 83 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 10 84 6. SFC OAM Model . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6.1. SFC OAM packet Marker . . . . . . . . . . . . . . . . . . 11 86 6.2. OAM packet processing and forwarding semantic . . . . . . 11 87 6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 12 88 6.4. OAM toolset applicability . . . . . . . . . . . . . . . . 12 89 6.4.1. ICMP Applicability . . . . . . . . . . . . . . . . . 12 90 6.4.2. Seamless BFD Applicability . . . . . . . . . . . . . 12 91 6.4.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . 13 92 6.4.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . 13 93 6.5. Security Considerations . . . . . . . . . . . . . . . . . 13 94 6.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 95 6.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 14 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 97 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 98 7.2. Informative References . . . . . . . . . . . . . . . . . 15 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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. Service Function Chaining is a concept that 107 provides for more than just the application of an ordered set of SFs 108 to selected traffic; rather, it describes a method for deploying SFs 109 in a way that enables dynamic ordering and topological independence 110 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 familiar with the material in these 119 documents. 121 This document provides 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 at SFC layer and the underlying Network, 144 Transport, Link, etc., layers. 146 o The service layer, refer to as the "Service Layer" in Figure 1, 147 consists of classifiers and service functions, and uses the 148 overlay network reach from a classifier to service functions and 149 service functions to service functions. 151 o The overlay network layer, refer to as the "Network" in Figure 1, 152 extends in between various service functions and is mostly 153 transparent to the service functions. It leverages various 154 overlay network technologies interconnecting service functions and 155 allows establishing of service function paths. 157 o The underlay network layer, refer to as the "Transport" in 158 Figure 1, is dictated by the networking technology of the PSN. It 159 may be either based on MPLS LSPs or IP. 161 o The link layer, refer to as the "Link" in Figure 1, is dependent 162 upon the physical technology used. Ethernet is a popular choice 163 for this layer, but other alternatives are deployed (e.g. POS, 164 DWDM etc...). 166 o----------------------Service Layer----------------------o 168 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 169 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 170 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 171 +------+ 172 o------VM1------o o--VM2--o o--VM3--o 174 o-----------------o-------------------o---------------o Network 176 o-----------------o-----------------------------------o Transport 178 o--------o--------o--------o--------o--------o--------o Link 180 Figure 1: SFC Layering Example 182 3. SFC OAM Components 184 The SFC operates at the service layer. For the purpose of defining 185 the OAM framework, the service layer is broken up into three distinct 186 components. 188 1. Service function component: A function providing a specific 189 service. OAM solutions for this component are to test the 190 service functions from any SFC aware network devices (i.e. 191 classifiers, controllers, other service nodes). 193 2. Service function chain component: An ordered set of service 194 functions. OAM solution for this component are to test the 195 service function chains and the service function paths. 197 3. Classifier component: A policy that describes the mapping from 198 flows to service function chains. OAM solutions for this 199 component are to test the validity of the classifiers. 201 Below figure illustrates an example where OAM for the three defined 202 components are used within the SFC environment. 204 +-Classifier +-Service Function Chain OAM 205 | OAM | 206 | | _________________________________________ 207 | \ /\ Service Function Chain \ 208 | +------+ \/ \ +---+ +---+ +---+ +---+ +---+ \ 209 +----> |Classi|...(+-> ) |SF1|---|SF2|---|SF4|---|SF6|---|SF7| ) 210 |fier | \ / +-^-+ +---+ +-|-+ +-^-+ +---+ / 211 +----|-+ \/_____|_______________|_______|_________ / 212 | | +-SF_OAM+ 213 +----SF_OAM----+ +---+ +---+ 214 +SF_OAM>|SF3| |SF5| 215 | +-^-+ +-^-+ 216 +------|---+ | | 217 |Controller| +-SF_OAM+ 218 +----------+ 219 Service Function OAM (SF_OAM) 221 Figure 2: SFC OAM for Three Components 223 It is expected that multiple SFC OAM solutions will be defined, many 224 targeting one specific component of the service layer. However, it 225 is critical that SFC OAM solutions together provide the coverage of 226 all three SFC OAM components: the service function component, the 227 service function chain component and the classifier component. 229 3.1. Service Function Component 231 3.1.1. Service Function Availability 233 One SFC OAM requirement for the service function component is to 234 allow an SFC aware network device to check the availability to a 235 specific service function, located on the same or different network 236 devices. Service function availability is an aspect which raises an 237 interesting question. How does one determine that a service function 238 is available? On one end of the spectrum, one might argue that a 239 service function is sufficiently available if the service node 240 (physical or virtual) hosting the service function is available and 241 is functional. On the other end of the spectrum, one might argue 242 that the service function availability can only be concluded if the 243 packet, after passing through the service function, was examined and 244 verified that the packet got expected service applied. 246 The former approach will likely not provide sufficient confidence to 247 the actual service function availability, i.e. a service node and a 248 service function are two different entities. The latter approach is 249 capable of providing an extensive verification, but comes with a 250 cost. Some service functions make direct modifications to packets, 251 while other service functions do not make any modifications to 252 packets. Additionally, purpose of some service functions is to, 253 conditionally, drop packets intentionally. In such case, packets 254 will not be coming out from the service function. The fact is that 255 there are many flavors of service functions available, and many more 256 flavors of service functions will likely be introduced in future. 257 Even a given service function may introduce a new functionality 258 within a service function (ex: a new signature in a firewall). The 259 cost of this approach is that verifier functions will need to be 260 continuously modified to "keep up" with new services coming out: lack 261 of extendibility. 263 This framework document provides a RECOMMENDED architectural model 264 where generalized approach is taken to verify that a service function 265 is sufficiently available. TBD - details will be provided in a later 266 revision. 268 3.1.2. Service Function Performance Measurement 270 Second SFC OAM requirement for the service function component is to 271 allow an SFC aware network device to check the loss and delay of a 272 specific service function, located on the same or different network 273 devices. TBD - details will be provided in a later revision. 275 3.2. Service Function Chain Component 277 3.2.1. Service Function Chain Availability 279 Verifying an SFC is a complicated process as the SFC could be 280 comprised of varying SF's. Thus, SFC requires the OAM layer to 281 perform validation and verification of SF's within an SFC Path, as 282 well as connectivity and fault isolation. 284 In order to perform service connectivity verification of an SFC, the 285 OAM could be initiated from any SFC aware network devices for end-to- 286 end paths or partial path terminating on a specific SF within the 287 SFC. This OAM function is to ensure the SF's chained together has 288 connectivity as it is intended to when SFC was established. 289 Necessary return code should be defined to be sent back in the 290 response to OAM packet, in order to qualify the verification. 292 When ECMP exists at the service layer on a given SFC, there must be 293 an ability to discover and traverse all available paths. 295 TBD - further details will be provided in a later revision. 297 3.2.2. Service Function Chain Performance Measurement 299 The ingress of the service function chain or an SFC aware network 300 device must have an ability to perform loss and delay measurements 301 over the service function chain as a unit (i.e. end-to-end) or to a 302 specific service function through the SFC. 304 3.3. Classifier Component 306 A classifier defines a flow and maps incoming traffic to a specific 307 SFC, and it is vital that the classifier is correctly defined and 308 functioning. The SFC OAM must be able to test the definition of 309 flows and the mapping functionality to expected SFCs. 311 4. SFC OAM Functions 313 Section 3 described SFC OAM operations required on each SFC 314 component. This section explores the same from the OAM functionality 315 point of view, which many will be applicable to multiple SFC 316 components. 318 Various SFC OAM requirements provides the need for various OAM 319 functions at different layers. Many of the OAM functions at 320 different layers are already defined and in existence. In order to 321 support SFC and SF's, these functions have to be enhanced to operate 322 a single SF to multiple SF's in an SFC and also multiple SFC's. 324 4.1. Connectivity Functions 326 Connectivity is mainly an on-demand function to verify that the 327 connectivity exists between network elements and the availability 328 exists to service functions. Ping is a common tool used to perform 329 this function. OAM messages SHOULD be encapsulated with necessary 330 SFC header and with OAM markings when testing the service function 331 chain component. OAM messages MAY be encapsulated with necessary SFC 332 header and with OAM markings when testing the service function 333 component. Some of the OAM functions performed by connectivity 334 functions are as follows: 336 o Verify the MTU size from a source to the destination SF or through 337 the SFC. This requires the ability for OAM packet to take 338 variable length packet size. 340 o Verify the packet re-ordering and corruption. 342 o Verify the policy of an SFC or SF using OAM packet. 344 o Verification and validating forwarding paths. 346 o Proactively test alternate or protected paths to ensure 347 reliability of network configurations. 349 4.2. Continuity Functions 351 Continuity is a model where OAM messages are sent periodically to 352 validate or verify the reachability to a given SF or through a given 353 SFC. This allows monitor network device to quickly detect failures 354 like link failures, network failures, service function outages or 355 service function chain outages. BFD is one such function which helps 356 in detecting failures quickly. OAM functions supported by continuity 357 check are as follows: 359 o Ability to provision continuity check to a given SF or through a 360 given SFC. 362 o Notifying the failure upon failure detection for other OAM 363 functions to take appropriate action. 365 4.3. Trace Functions 367 Tracing is an important OAM function that allows the operation to 368 trigger an action (ex: response generation) from every transit device 369 on the tested layer. This function is typically useful to gather 370 information from every transit devices or to isolate the failure 371 point towards an SF or through an SFC. Some of the OAM functions 372 supported by trace functions are: 374 o Ability to trigger action from every transit device on the tested 375 layer towards an SF or through an SFC, using TTL or other means. 377 o Ability to trigger every transit device to generate response with 378 OAM code(s) on the tested layer towards an SF or through an SFC, 379 using TTL or other means. 381 o Ability to discover and traverse ECMP paths within an SFC. 383 o Ability to skip un-supported SF's while tracing SF's in an SFC. 385 4.4. Performance Measurement Function 387 Performance management functions involve measuring of packet loss, 388 delay, delay variance, etc. These measurements could be measured 389 pro-actively and on-demand. 391 SFC OAM framework should provide the ability to perform packet loss 392 for an SFC. In an SFC, there are various SF's chained together. 393 Measuring packet loss is very important function. Using on-demand 394 function, the packet loss could be measured using statistical means. 395 Using OAM packets, the approximation of packet loss for a given SFC 396 could be measured. 398 Delay within an SFC could be measured from the time it takes for a 399 packet to traverse the SFC from ingress SF to egress SF. As the 400 SFC's are generally unidirectional in nature, measurement of one-way 401 delay is important. In order to measure one-way delay, the clocks 402 have to be synchronized using NTP, GPS, etc. 404 Delay variance could also be measured by sending OAM packets and 405 measuring the jitter between the packets passing through the SFC. 407 Some of the OAM functions supported by the performance measurement 408 functions are: 410 o Ability to measure the packet processing delay of a service 411 function or a service function path along an SFC. 413 o Ability to measure the packet loss of a service function or a 414 service function path along an SFC. 416 5. Gap Analysis 418 This Section identifies various OAM functions available at different 419 levels. It will also identify various gaps, if not all, existing 420 within the existing toolset, to perform OAM function on an SFC. 422 5.1. Existing OAM Functions 424 There are various OAM tool sets available to perform OAM function and 425 network layer, protocol layers and link layers. These OAM functions 426 could validate some of the underlay and overlay networks. Tools like 427 ping and trace are in existence to perform connectivity check and 428 tracing intermediate hops in a network. These tools support 429 different network types like IP, MPLS, TRILL etc. There is also an 430 effort to extend the tool set to provide connectivity and continuity 431 checks within overlay networks. BFD is another tool which helps in 432 detection of data forwarding failures. 434 +----------------+--------------+-------------+--------+------------+ 435 | Layer | Connectivity | Continuity | Trace | Performance| 436 +----------------+--------------+-------------+--------+------------+ 437 | Underlay N/w | Ping | E-OAM, BFD | Trace | IPPM, MPLS | 438 +----------------+--------------+-------------+--------+------------+ 439 | Overlay N/w | Ping | BFD, NVo3 | Trace | IPPM | 440 +----------------+--------------+-------------+--------+------------+ 441 | SF | None + None + None + None | 442 +----------------+--------------+-------------+--------+------------+ 443 | SFC | None + None + None + None | 444 +----------------+--------------+-------------+--------+------------+ 445 Figure 3: OAM Tool GAP Analysis 447 +----------------+--------------+-------------+--------+------------+ 448 | Layer |Configuration |Orchestration|Topology|Notification| 449 +----------------+--------------+-------------+--------+------------+ 450 | Underlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog| 451 +----------------+--------------+-------------+--------+------------+ 452 | Overlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog| 453 +----------------+--------------+-------------+--------+------------+ 454 | SF |CLI + CLI + None + None | 455 +----------------+--------------+-------------+--------+------------+ 456 | SFC |CLI + CLI + None + None | 457 +----------------+--------------+-------------+--------+------------+ 458 Figure 4: OAM Tool GAP Analysis (contd.) 460 5.2. Missing OAM Functions 462 As shown in Figure 3, OAM functions for SFC are not standardized yet. 463 Hence, there are no standard based tools available to verify SF and 464 SFC. 466 5.3. Required OAM Functions 468 Primary OAM functions exist for network, transport, link and other 469 layers. Tools like ping, trace, BFD, etc., exist in order to perform 470 these OAM functions. Configuration, orchestration and manageability 471 of SF and SFC could be performed using CLI, Netconf etc. 473 As seen in Figure 3 and 4, for configuration, manageability and 474 orchestration, providing data and information models for SFC is very 475 much needed. With virtualized SF and SFC, manageability of these 476 functions has to be done programmatically. 478 6. SFC OAM Model 480 This section describes the operational aspects of SFC OAM at Service 481 layer to perform the SFC OAM function defined in Section 4 and 482 analyze the applicability of various existing OAM toolsets in the 483 Service layer. 485 6.1. SFC OAM packet Marker 487 SFC OAM function described in Section 4 performed at service layer or 488 overlay network layer must mark the packet as OAM packet that can be 489 used by the relevant nodes to differentiate the OAM packet from data 490 packets. The base header defined in Section 3.2 of 491 [I-D.ietf-sfc-nsh] assigns a bit to indicate OAM packets. When NSH 492 encapsulation is used at the service layer, the O bit must be set to 493 differentiate the OAM packet. Any other overlay encapsulations used 494 in future must have a way to mark the packet as OAM packet. 496 6.2. OAM packet processing and forwarding semantic 498 Upon receiving OAM packet, SF may choose to discard the packet if it 499 does not support OAM functionality or if the local policy prevent it 500 from processing OAM packet. When SF supports OAM functionality, it 501 is desired to process the packet and respond back accordingly that 502 helps with end-to-end verification. To avoid hitting any performance 503 impact, SF can rate limit the number of OAM packets processed. 505 Service Function Forwarder (SFF) may choose not to forward the OAM 506 packet to SF if the SF does not support OAM function or if the policy 507 does not allow to forward OAM packet to SF. SFF may choose to skip 508 the SF, modify the header and forward to next SFC node in the chain. 509 How SFF detects if the connected SF supports or allowed to process 510 OAM packet is outside the scope of this document. It could be a 511 configuration paramater instructed by the controller or can be a 512 dynamic negotiation between SF and SFF. 514 If the SFF receiving the OAM packet is the last SFF in the chain, it 515 must send a relevant response to the initiator of the OAM packet. 516 Depending on the type of OAM solution and tool set used, the response 517 could be a simple response (ICMP reply or BFD reply packet) or could 518 include additional data from the received OAM packet (like stats data 519 consolidated along the path). The proposed solution should detail it 520 further. 522 The classifier will normally be the node that initiates the OAM 523 packet in order to validate the local classification policy or to 524 validate the SFC or SFP. When the classifier initiates OAM packet, 525 it must set the OAM marker in the overlay encapsulation. 527 6.3. OAM Function Types 529 As described in Section 4, there are different OAM functions that may 530 require different OAM solution or tool sets. While the presence of 531 OAM marker in overlay header (For ex: O bit in NSH header) indicates 532 it as OAM packet, it is not sufficient to indicate what OAM function 533 the packet is intended for. We can use the Next Protocol field in 534 NSH header to indicate what OAM function is it intended to or what 535 toolset is used. 537 6.4. OAM toolset applicability 539 As described in Section 5.1, there are different tool sets available 540 to perform OAM functions at different layers. This section describes 541 the applicability of some of the available tool sets in service 542 layer. 544 6.4.1. ICMP Applicability 546 [RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 547 network respectively. It explains how ICMP messages can be used to 548 test the network reachability between different end points and 549 perform basic network diagnostics. 551 ICMP could be leveraged for basic OAM functions like SF availability 552 or SFC availability. Initiator can generate ICMP echo message and 553 control the overlay encapsulation header to get the response from 554 relevant node. For example, a classifier initiating OAM can generate 555 ICMP echo message can set the TTL field in NSH header to 255 to get 556 the response from last SFF and thereby test the SFC availability. 557 Alternately, Initiator can set the TTL to other value to get the 558 response from specific SF and there by test the SF availability. 559 Alternately, Initiator could send OAM packets with sequentially 560 incrementing the TTL in NSH header to trace the Service Function 561 Path. 563 It could be observed that ICMP at its current stage may not be able 564 to perform all SFC OAM functions, but as explained above, it can be 565 used to test the basic OAM functions. 567 6.4.2. Seamless BFD Applicability 569 [RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism 570 for fast failure detection. [RFC5881] and [RFC5884] defines the 571 applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] 572 defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. 573 [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. 575 S-BFD could be leveraged to perform SF or SFC availability. 576 Classifier or Initiator could generate BFD control packet and set the 577 "Your Discriminator" value as last SFF in the control packet. Upon 578 receiving the control packet, last SFF will reply back with relevant 579 DIAG code. We could also use the TTL field in NSH header to perform 580 the SF availability. For example, Initiator can set the "Your 581 Discriminator" value to the SF that is intended to be tested and set 582 the TTL field in NSH header in a way that it will be expired on the 583 relevant SF. How the initiator gets the Discriminator value of the 584 SF is outside the scope of this document. 586 6.4.3. In-Situ OAM 588 [I-D.brockners-proof-of-transit] defines the mechanism to perform 589 proof of transit to securely verify if a packet traversed the 590 relevant path or chain. While the mechanism is defined inband (i.e, 591 it will be included in data packets), it can be used to perform 592 various SFC OAM functions as well. 594 In-Situ OAM could be used with O bit set and perform SF availability, 595 SFC availability of performance measurement. 597 6.4.4. SFC Traceroute 599 [I-D.penno-sfc-trace] defines a protocol that checks for path 600 liveliness and trace the service hops in any SFP. Section 3 of 601 [I-D.penno-sfc-trace] defines the SFC trace packet format while 602 section 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF 603 and SFF respectively. 605 Initiator can control the SIL in SFC trace packet to perform SF and 606 SFC availability test. 608 6.5. Security Considerations 610 SFC and SF OAM must provide mechanisms for: 612 o Preventing usage of OAM channel for DDOS attacks. 614 o OAM packets meant for a given SFC should not get leaked beyond 615 that SFC. 617 o Prevent OAM packets to leak the information of an SFC beyond its 618 administrative domain. 620 6.6. IANA Considerations 622 No action is required by IANA for this document. 624 6.7. Acknowledgements 626 TBD 628 7. References 630 7.1. Normative References 632 [I-D.brockners-proof-of-transit] 633 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 634 Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof 635 of Transit", draft-brockners-proof-of-transit-03 (work in 636 progress), March 2017. 638 [I-D.ietf-sfc-nsh] 639 Quinn, P. and U. Elzur, "Network Service Header", draft- 640 ietf-sfc-nsh-13 (work in progress), June 2017. 642 [I-D.penno-sfc-trace] 643 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 644 "Services Function Chaining Traceroute", draft-penno-sfc- 645 trace-03 (work in progress), September 2015. 647 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 648 RFC 792, DOI 10.17487/RFC0792, September 1981, 649 . 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, 653 DOI 10.17487/RFC2119, March 1997, 654 . 656 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 657 Control Message Protocol (ICMPv6) for the Internet 658 Protocol Version 6 (IPv6) Specification", RFC 4443, 659 DOI 10.17487/RFC4443, March 2006, 660 . 662 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 663 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 664 . 666 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 667 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 668 DOI 10.17487/RFC5881, June 2010, 669 . 671 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 672 "Bidirectional Forwarding Detection (BFD) for MPLS Label 673 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 674 June 2010, . 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 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 687 Pallagatti, "Seamless Bidirectional Forwarding Detection 688 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 689 . 691 [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless 692 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, 693 and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, 694 . 696 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 697 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 698 Switched (MPLS) Data-Plane Failures", RFC 8029, 699 DOI 10.17487/RFC8029, March 2017, 700 . 702 7.2. Informative References 704 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 705 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 706 Acronym in the IETF", BCP 161, RFC 6291, 707 DOI 10.17487/RFC6291, June 2011, 708 . 710 Authors' Addresses 712 Sam K. Aldrin 713 Google 715 Email: aldrin.ietf@gmail.com 717 Carlos Pignataro (editor) 718 Cisco Systems, Inc. 720 Email: cpignata@cisco.com 722 Nagendra Kumar (editor) 723 Cisco Systems, Inc. 725 Email: naikumar@cisco.com 727 Nobo Akiya 728 Big Switch Networks 730 Email: nobo.akiya.dev@gmail.com 732 Ram Krishnan 733 Dell 735 Email: ramkri123@gmail.com 737 Anoop Ghanwani 738 Dell 740 Email: anoop@alumni.duke.edu