idnits 2.17.1 draft-ietf-sfc-oam-framework-11.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 (September 19, 2019) is 1680 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-02 == Outdated reference: A later version (-08) exists of draft-ietf-sfc-proof-of-transit-03 Summary: 0 errors (**), 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: March 22, 2020 N. Kumar, Ed. 6 Cisco 7 R. Krishnan 8 VMware 9 A. Ghanwani 10 Dell 11 September 19, 2019 13 Service Function Chaining (SFC) 14 Operations, Administration and Maintenance (OAM) Framework 15 draft-ietf-sfc-oam-framework-11 17 Abstract 19 This document provides a reference framework for Operations, 20 Administration and Maintenance (OAM) for Service Function Chaining 21 (SFC). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in RFC 28 2119 [RFC2119] RFC 8174 [RFC8174] when and only when, they appear in 29 all capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 22, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 4 67 1.2. Acronyms and Terminology . . . . . . . . . . . . . . . . 4 68 1.2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2.2. Terminology . . . . . . . . . . . . . . . . . . . . . 5 70 2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 5 71 3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. The SF Component . . . . . . . . . . . . . . . . . . . . 7 73 3.1.1. SF Availability . . . . . . . . . . . . . . . . . . . 7 74 3.1.2. SF Performance Measurement . . . . . . . . . . . . . 8 75 3.2. The SFC Component . . . . . . . . . . . . . . . . . . . . 8 76 3.2.1. SFC Availability . . . . . . . . . . . . . . . . . . 8 77 3.2.2. SFC Performance Measurement . . . . . . . . . . . . . 9 78 3.3. The Classifier Component . . . . . . . . . . . . . . . . 9 79 3.4. Underlay Network . . . . . . . . . . . . . . . . . . . . 9 80 3.5. Overlay Network . . . . . . . . . . . . . . . . . . . . . 10 81 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 10 82 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 10 83 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 11 84 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 11 85 4.4. Performance Management Functions . . . . . . . . . . . . 12 86 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 12 87 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 12 88 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 13 89 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 13 90 6. Candidate SFC OAM Tools . . . . . . . . . . . . . . . . . . . 13 91 6.1. SFC OAM Packet Marker . . . . . . . . . . . . . . . . . . 13 92 6.2. OAM Packet Processing and Forwarding Semantic . . . . . . 14 93 6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 14 94 6.4. OAM Toolset Applicability . . . . . . . . . . . . . . . . 15 95 6.4.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . 15 96 6.4.2. BFD/Seamless-BFD . . . . . . . . . . . . . . . . . . 15 97 6.4.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . 16 98 6.4.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . 16 99 7. Manageability Considerations . . . . . . . . . . . . . . . . 16 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 103 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 106 12.2. Informative References . . . . . . . . . . . . . . . . . 18 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 109 1. Introduction 111 Service Function Chaining (SFC) enables the creation of composite 112 services that consist of an ordered set of Service Functions (SF) 113 that are to be applied to packets and/or frames selected as a result 114 of classification [RFC7665]. SFC is a concept that provides for more 115 than just the application of an ordered set of SFs to selected 116 traffic; rather, it describes a method for deploying SFs in a way 117 that enables dynamic ordering and topological independence of those 118 SFs as well as the exchange of metadata between participating 119 entities. The foundations of SFC are described in the following 120 documents: 122 o SFC Problem Statement [RFC7498] 124 o SFC Architecture [RFC7665] 126 The reader is assumed to be familiar with the material in [RFC7665]. 128 This document provides a reference framework for Operations, 129 Administration and Maintenance (OAM, [RFC6291]) of SFC. 130 Specifically, this document provides: 132 o In Section 2, an SFC layering model; 134 o In Section 3, aspects monitored by SFC OAM; 136 o In Section 4, functional requirements for SFC OAM; 138 o In Section 5, a gap analysis for SFC OAM. 140 o In Section 6, applicability of various OAM tools. 142 o In Section 7, manageability considerations for SF and SFC. 144 SFC OAM solution documents should refer to this document to indicate 145 the SFC OAM component and the functionality they target. 147 OAM controllers are assumed to be within the same administrative 148 domain as the target SFC enabled domain. 150 1.1. Document Scope 152 The focus of this document is to provide an architectural framework 153 for SFC OAM, particularly focused on the aspect of the Operations 154 component within OAM. Actual solutions and mechanisms are outside 155 the scope of this document. 157 1.2. Acronyms and Terminology 159 1.2.1. Acronyms 161 SFC: Service Function Chain 163 SFF: Service Function Forwarder 165 SF: Service Function 167 SFP: Service Function Path 169 RSP: Rendered Service Path 171 NSH: Network Service Header 173 VM: Virtual Machines 175 OAM: Operations, Administration and Maintenance 177 IPPM: IP Performance Measurement 179 BFD: Bidirectional Forwarding Detection 181 NVo3: Network Virtualization over Layer3 183 SNMP: Simple Network Management Protocol 185 NETCONF: Network Configuration Protocol 187 E-OAM: Ethernet OAM 189 MPLS_PM: MPLS Performance Measurement 191 1.2.2. Terminology 193 This document uses the terminologies defined in [RFC7665], [RFC8300], 194 and so the readers are expected to be familiar with the 195 terminologies. 197 2. SFC Layering Model 199 Multiple layers come into play for implementing the SFC. These 200 include the service layer and the underlying layers (Network Layer, 201 Link Layer, etc.). 203 o The service layer, which consists of SFC data plane elements that 204 includes classifiers, Service Functions (SF), Service Function 205 Forwarders (SFF), and SFC Proxies. This layer uses the overlay 206 network for ensuring connectivity between SFC data plane elements. 208 o The overlay network layer, which leverages various overlay network 209 technologies interconnecting SFC data plane elements and allows 210 establishing Service Function Paths (SFPs). This layer is mostly 211 transparent to the SFC data plane elements. 213 o The underlay network layer, which is dictated by the networking 214 technology deployed within a network (e.g., IP, MPLS) 216 o The link layer, which is tightly coupled with the physical 217 technology used. Ethernet is a popular choice for this layer, but 218 other alternatives are deployed (e.g. POS, DWDM). The same or 219 distinct link layer technologies may be used in each leg shown in 220 Figure 1. 222 o----------------------Service Layer----------------------o 224 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 225 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 226 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 227 +------+ 228 <------VM1------> <--VM2--> <--VM3--> 230 ^-----------------^-------------------^---------------^ Overlay N/W 232 o-----------------o-------------------o---------------o Underlay N/W 234 o--------o--------o--------o--------o--------o--------o Link 236 Figure 1: SFC Layering Example 238 In Figure 1, the service layer element such as classifier and SF are 239 depicted as virtual machines that are interconnected using an overlay 240 network. The underlay network may comprise of multiple intermediate 241 nodes but not shown in the figure that provides underlay connectivity 242 between the service layer elements. 244 While Figure 1 depicts an example where SFs are enabled as virtual 245 entities, the SFC architecture does not make any assumptions on how 246 the SFC data plane elements are deployed. The SFC architecture is 247 flexible and accommodates physical or virtual entity deployment. SFC 248 OAM accounts for this flexibility and accordingly it is applicable 249 whether SFC data plane elements are deployed directly on physical 250 hardware, as one or more Virtual Machines, or any combination 251 thereof. 253 3. SFC OAM Components 255 The SFC operates at the service layer. For the purpose of defining 256 the OAM framework, the service layer is broken up into three distinct 257 components: 259 1. SF component: OAM functions applicable at this component includes 260 testing the SFs from any SFC-aware network devices (e.g., 261 classifiers, controllers, other service nodes). Testing an SF 262 may not be restricted to connectivity to the SF, but also whether 263 the SF is providing its intended service. Refer to Section 3.1.1 264 for a more detailed discussion. 266 2. SFC component: OAM functions applicable at this component 267 includes (but are not limited to) testing the service function 268 chains and the SFPs, validaion of the correlation between an SFC 269 and the actual forwarding path followed by a packet matching that 270 SFC, i.e. the Rendered Service Path (RSP). Some of the hops of 271 an SFC may not be visible when Hierarchical Service Function 272 Chaining (hSFC) [RFC8459] is in use. In such schemes, it is the 273 responsibility of the Internal Boundary Node (IBN) to glue the 274 connectivity between different levels for end-to-end OAM 275 functionality. 277 3. Classifier component: OAM functions applicable at this component 278 includes testing the validity of the classification rules and 279 detecting any incoherence among the rules installed in different 280 classifiers. 282 Figure 2 illustrates an example where OAM for the three defined 283 components are used within the SFC environment. 285 +-Classifier +-Service Function Chain OAM 286 | OAM | 287 | | ___________________________________________ 288 | \ /\ Service Function Chain \ 289 | \ / \ +---+ +---+ +-----+ +---+ \ 290 | \ / \ |SF1| |SF2| |Proxy|--|SF3| \ 291 | +------+ \/ \ +---+ +---+ +-----+ +---+ \ 292 +----> | |....(+-> ) | | | ) 293 |Classi| \ / +-----+ +-----+ +-----+ / 294 |fier | \ / | SFF1|----| SFF2|----| SFF3| / 295 | | \ / +--^--+ +-----+ +-----+ / 296 +----|-+ \/_________|________________________________/ 297 | | 298 +-------SF_OAM-------+ 299 +---+ +---+ 300 +SF_OAM>|SF3| |SF5| 301 | +-^-+ +-^-+ 302 +------|---+ | | 303 |Controller| +-SF_OAM+ 304 +----------+ 305 Service Function OAM (SF_OAM) 307 Figure 2: SFC OAM Components 309 It is expected that multiple SFC OAM solutions will be defined, each 310 targeting one specific component of the service layer. However, it 311 is critical that SFC OAM solutions together provide the coverage of 312 all three SFC OAM components: the SF component, the SFC component, 313 and the classifier component. 315 3.1. The SF Component 317 3.1.1. SF Availability 319 One SFC OAM requirement for the SF component is to allow an SFC-aware 320 network device to check the availability of a specific SF (instance), 321 located on the same or different network device(s). The SF 322 availability may be performed to check the availability of any 323 instance of a specific SFn or it can be a specific instance of a SF. 324 SF availability is an aspect that raises an interesting question -- 325 How to determine that a service function is available?. On one end 326 of the spectrum, one might argue that an SF is sufficiently available 327 if the service node (physical or virtual) hosting the SF is available 328 and is functional. On the other end of the spectrum, one might argue 329 that the SF's availability can only be concluded if the packet, after 330 passing through the SF, was examined and it was verified that the 331 packet did indeed get the got expected service. 333 The former approach will likely not provide sufficient confidence to 334 the actual SF availability, i.e. a service node and a SF are two 335 different entities. The latter approach is capable of providing an 336 extensive verification, but comes at a cost. Some SFs make direct 337 modifications to packets, while others do not. Additionally, the 338 purpose of some SFs may be to, conditionally, drop packets 339 intentionally. In such cases, it is normal behavior that certain 340 packets will not be egressing out from the service function. The OAM 341 mechanism needs to take into account such SF specifics when assessing 342 SF availability. Note that there are many flavors of SFs available, 343 and many more that are likely be introduced in future. Even a given 344 SF may introduce a new functionality (e.g., a new signature in a 345 firewall). The cost of this approach is that the OAM mechanism for 346 some SF will need to be continuously modified in order to "keep up" 347 with new functionality being introduced: lack of extendibility. 349 This framework document provides a RECOMMENDED framework where a 350 generalized approach is taken to verify that a SF is sufficiently 351 available (i.e., an adequate granularity to provide a basic SF 352 service). More specifics on the mechanism to characterize SF- 353 specific OAM to validate the service offering are outside the scope 354 of this document. Those fine-grained mechanisms are implementation- 355 and deployment-specific. 357 3.1.2. SF Performance Measurement 359 The second SFC OAM requirement for the SF component is to allow an 360 SFC-aware network device to check the performance metrics such as 361 loss and delay induced by a specific SF for processing legitimate 362 traffic. The performance can be a passive measurement by using live 363 traffic or can be active measurement by using synthetic probe 364 packets. 366 On the one hand, the performance of any specific SF can be quantified 367 by measuring the loss and delay metrics of the traffic from SFF to 368 the respective SF, while on the other hand, the performance can be 369 measured by leveraging the loss and delay metrics from the respective 370 SFs. The latter requires SF involvement to perform the measurement 371 while the former does not. 373 3.2. The SFC Component 375 3.2.1. SFC Availability 377 An SFC could be comprised of varying SFs and so the OAM layer is 378 required to perform validation and verification of SFs within an SFP, 379 in addition to connectivity verification and fault isolation. 381 In order to perform service connectivity verification of an SFC/SFP, 382 the OAM functions could be initiated from any SFC-aware network 383 devices of an SFC-enabled domain for end-to-end paths, or partial 384 paths terminating on a specific SF, within the SFC/SFP. The goal of 385 this OAM function is to ensure the SFs chained together have 386 connectivity as was intended at the time when the SFC was 387 established. The necessary return codes should be defined for 388 sending back in the response to the OAM packet, in order to complete 389 the verification. 391 When ECMP is in use at the service layer for any given SFC, there 392 MUST be the ability to discover and traverse all available paths. 394 A detailed explanation of the mechanism is outside the scope of this 395 document and is expected to be included in the actual solution 396 document. 398 3.2.2. SFC Performance Measurement 400 Any SFC-aware network device SHOULD have the ability to make 401 performance measurements over the entire SFC (i.e., end-to-end) or to 402 a specific segment of SFs within the SFC. 404 3.3. The Classifier Component 406 A classifier maintains the classification rules that map a flow to a 407 specific SFC. It is vital that the classifier is correctly 408 configured with updated classification rules and is functioning as 409 expected. The SFC OAM must be able to validate the classification 410 rules by assessing whether a flow is appropriately mapped to the 411 relevant SFC. Sample OAM packets can be presented to the classifiers 412 to assess the behavior with regard to a given classification entry. 414 The Classifier availability check may be performed to check the 415 availability of the classifier to apply the rules and classify the 416 traffic flows. Any SFC-aware network device SHOULD have the ability 417 to perform availability check of the classifier component for each 418 SFC. 420 Any SFC-aware network device SHOULD have the ability to perform 421 performance measurement of the classifier component for each SFC. 423 3.4. Underlay Network 425 The underlay network provides connectivity between the SFC components 426 and so the availability or the performance of the underlay network 427 directly impacts the SFC OAM. 429 Any SFC-aware network device MAY have the ability to perform 430 availability check or performance measurement of the underlay 431 network. 433 3.5. Overlay Network 435 The overlay network establishes the service plane between the SFC 436 components and are mostly transparent to the SFC data plane elements. 438 Any SFC-aware network device MAY have the ability to perform 439 availability check or performance measurement of the overlay network. 441 4. SFC OAM Functions 443 Section 3 described SFC OAM operations that are required on each SFC 444 component. This section explores SFC OAM functions that are 445 applicable for more than one SFC components. 447 The various SFC OAM requirements listed in Section 3 highlighted the 448 need for various OAM functions at different layers. As listed in 449 Section 5.1, various OAM functions are in existence that are defined 450 to perform OAM functionality at different layers. In order to apply 451 such OAM functions at the service layer, they need to be enhanced to 452 operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in 453 multiple SFCs. 455 4.1. Connectivity Functions 457 Connectivity is mainly an on-demand function to verify that the 458 connectivity exists between certain network elements and that the SFs 459 are available. For example, LSP Ping [RFC8029] is a common tool used 460 to perform this function for an MPLS underlay network. OAM messages 461 SHOULD be encapsulated with necessary SFC header and with OAM 462 markings when testing the SFC component. OAM messages MAY be 463 encapsulated with the necessary SFC header and with OAM markings when 464 testing the SF component. Some of the OAM functions performed by 465 connectivity functions are as follows: 467 o Verify the Path MTU from a source to the destination SF or through 468 the SFC. This requires the ability for the OAM packet to be of 469 variable length packet size. 471 o Verify any packet re-ordering and corruption. 473 o Verify the policy of an SFC or SF. 475 o Verification and validation of forwarding paths. 477 o Proactively test alternate or protected paths to ensure 478 reliability of network configurations. 480 4.2. Continuity Functions 482 Continuity is a model where OAM messages are sent periodically to 483 validate or verify the reachability to a given SF within an SFC or 484 for the entire SFC. This allows a monitoring network device (such as 485 the classifier or controller) to quickly detect failures such as link 486 failures, network element failures, SF outages, or SFC outages. BFD 487 [RFC5880] is one such function which helps in detecting failures 488 quickly. OAM functions supported by continuity function are as 489 follows: 491 o Ability to provision continuity check to a given SF within an SFC 492 or for the entire SFC. 494 o Proactively test alternate or protected paths to ensure 495 reliability of network configurations. 497 o Notifying the detected failures to other OAM functions or 498 applications to take appropriate action. 500 4.3. Trace Functions 502 Tracing is an OAM function that allows the operation to trigger an 503 action (e.g. response generation) from every transit device (e.g. 504 SFF, SF, SFC Proxy) on the tested layer. This function is typically 505 useful for gathering information from every transit devices or for 506 isolating the failure point to a specific SF within an SFC or for an 507 entire SFC. Some of the OAM functions supported by trace functions 508 are: 510 o Ability to trigger action from every transit device at the SFC 511 layer, using TTL or other means. 513 o Ability to trigger every transit device at the SFC layer to 514 generate a response with OAM code(s), using TTL or other means. 516 o Ability to discover and traverse ECMP paths within an SFC. 518 o Ability to skip SFs that do not support OAM while tracing SFs in 519 an SFC. 521 4.4. Performance Management Functions 523 Performance management functions involve measuring of packet loss, 524 delay, delay variance, etc. These performance metrics may be 525 measured pro-actively or on-demand. 527 SFC OAM should provide the ability to measure packet loss for an SFC. 528 On-demand measurement can be used to estimate packet loss using 529 statistical methods. Measuring the loss of OAM packets, an 530 approximation of packet loss for a given SFC can be derived. 532 Delay within an SFC could be measured based on the time it takes for 533 a packet to traverse the SFC from the ingress SFC node to the egress 534 SFF. As SFCs are unidirectional in nature, measurement of one-way 535 delay [RFC7679] is important. In order to measure one-way delay, 536 time synchronization MUST be supported by means such as NTP, PTP, 537 GPS, etc. 539 One-way delay variation [RFC3393] could also be calculated by sending 540 OAM packets and measuring the jitter between the packets passing 541 through an SFC. 543 Some of the OAM functions supported by the performance measurement 544 functions are: 546 o Ability to measure the packet processing delay induced by a single 547 SF or the one-way delay to traverse an SFP bound to a given SFC. 549 o Ability to measure the packet loss [RFC7680] within an SF or an 550 SFP bound to a given SFC. 552 5. Gap Analysis 554 This section identifies various OAM functions available at different 555 levels introduced in Section 2. It also identifies various gaps that 556 exist within the current toolset for performing OAM functions 557 required for SFC. 559 5.1. Existing OAM Functions 561 There are various OAM tool sets available to perform OAM functions 562 within various layers. These OAM functions may be used to validate 563 some of the underlay and overlay networks. Tools like ping and trace 564 are in existence to perform connectivity check and tracing of 565 intermediate hops in a network. These tools support different 566 network types like IP, MPLS, TRILL, etc. There is also an effort to 567 extend the tool set to provide connectivity and continuity checks 568 within overlay networks. BFD is another tool which helps in 569 detecting data forwarding failures. The orchestration tool may be 570 used for network and service orchestration function. Tables 3 and 4 571 are not exhaustive. 573 Table 3: OAM Tool GAP Analysis 574 +----------------+--------------+-------------+--------+------------+ 575 | Layer | Connectivity | Continuity | Trace | Performance| 576 +----------------+--------------+-------------+--------+------------+ 577 | Underlay N/w | Ping |E-OAM, BFD | Trace | IPPM, | 578 | | | | | MPLS_PM | 579 +----------------+--------------+-------------+--------+------------+ 580 | Overlay N/w | Ping |BFD, NVo3 OAM| Trace | IPPM | 581 +----------------+--------------+-------------+--------+------------+ 582 | Classifier | Ping |BFD | Trace | None | 583 +----------------+--------------+-------------+--------+------------+ 584 | SF | None | None | None | None | 585 +----------------+--------------+-------------+--------+------------+ 586 | SFC | None | None | None | None | 587 +----------------+--------------+-------------+--------+------------+ 589 5.2. Missing OAM Functions 591 As shown in Table 3, there are no standards-based tools available for 592 the verification of SFs and SFCs. 594 5.3. Required OAM Functions 596 Primary OAM functions exist for underlying layers. Tools like ping, 597 trace, BFD, etc. exist in order to perform these OAM functions. 599 6. Candidate SFC OAM Tools 601 This section describes the operational aspects of SFC OAM at the 602 service layer to perform the SFC OAM function defined in Section 4 603 and analyzes the applicability of various existing OAM toolsets in 604 the service layer. 606 6.1. SFC OAM Packet Marker 608 The SFC OAM function described in Section 4 performed at the service 609 layer or overlay network layer must mark the packet as an OAM packet 610 so that relevant nodes can differentiate an OAM packet from data 611 packets. The base header defined in Section 2.2 of [RFC8300] assigns 612 a bit to indicate OAM packets. When NSH encapsulation is used at the 613 service layer, the O bit must be set to differentiate the OAM packet. 615 Any other overlay encapsulations used in future must have a way to 616 mark the packet as OAM packet. 618 6.2. OAM Packet Processing and Forwarding Semantic 620 Upon receiving an OAM packet, SFC-aware SFs may choose to discard the 621 packet if it does not support OAM functionality or if the local 622 policy prevents them from processing the OAM packet. When an SF 623 supports OAM functionality, it is desirable to process the packet and 624 provide an appropriate response to allow end-to-end verification. To 625 limit performance impact due to OAM, SFC-aware SFs should rate limit 626 the number of OAM packets processed. 628 An SFF may choose not to forward the OAM packet to an SF if the SF 629 does not support OAM or if the policy does not allow to forward OAM 630 packet to an SF. The SFF may choose to skip the SF, modify the 631 header and forward to next SFC node in the chain. It should be noted 632 that skipping an SF might have implication on some OAM functions 633 (e.g. the delay measurement may not be accurate). The method by 634 which an SFF detects if the connected SF supports or is allowed to 635 process OAM packets is outside the scope of this document. It could 636 be a configuration parameter instructed by the controller or it can 637 be done by dynamic negotiation between the SF and SFF. 639 If the SFF receiving the OAM packet bound to a given SFC is the last 640 SFF in the chain, it must send a relevant response to the initiator 641 of the OAM packet. Depending on the type of OAM solution and tool 642 set used, the response could be a simple response (such as ICMP 643 reply) or could include additional data from the received OAM packet 644 (like statistical data consolidated along the path). The details are 645 expected to be covered in the solution documents. 647 Any SFC-aware node that initiates an OAM packet must set the OAM 648 marker in the overlay encapsulation. 650 6.3. OAM Function Types 652 As described in Section 4, there are different OAM functions that may 653 require different OAM solutions. While the presence of the OAM 654 marker in the overlay header (e.g., O bit in the NSH header) 655 indicates it as OAM packet, it is not sufficient to indicate what OAM 656 function the packet is intended for. The Next Protocol field in NSH 657 header may be used to indicate what OAM function is intended to or 658 what toolset is used. 660 6.4. OAM Toolset Applicability 662 As described in Section 5.1, there are different tool sets available 663 to perform OAM functions at different layers. This section describes 664 the applicability of some of the available toolsets in the service 665 layer. 667 6.4.1. ICMP 669 [RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 670 network respectively. It explains how ICMP messages can be used to 671 test the network reachability between different end points and 672 perform basic network diagnostics. 674 ICMP could be leveraged for connectivity function (defined in 675 Section 4.1) to verify the availability of SF or SFC. The Initiator 676 can generate an ICMP echo request message and control the service 677 layer encapsulation header to get the response from relevant node. 678 For example, a classifier initiating OAM can generate ICMP echo 679 request message, can set the TTL field in NSH header to 255 to get 680 the response from last SFF and thereby test the SFC availability. 681 Alternately, the initiator can set the TTL to some other value to get 682 the response from a specific SFs and there by test partial SFC 683 availability. Alternately, the initiator could send OAM packets with 684 sequentially incrementing the TTL in the NSH to trace the SFP. 686 It could be observed that ICMP at its current stage may not be able 687 to perform all required SFC OAM functions, but as explained above, it 688 can be used for some of the connectivity functions. 690 6.4.2. BFD/Seamless-BFD 692 [RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism 693 for failure detection. [RFC5881] and [RFC5884] defines the 694 applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] 695 defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. 696 [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. 698 BFD or S-BFD could be leveraged to perform continuity function for SF 699 or SFC. An initiator could generate a BFD control packet and set the 700 "Your Discriminator" value as last SFF in the control packet. Upon 701 receiving the control packet, the last SFF in the SFC will reply back 702 with relevant DIAG code. The TTL field in the NSH header could be 703 used to perform partial SFC availability. For example, the initiator 704 can set the "Your Discriminator" value to the SF that is intended to 705 be tested and set the TTL field in NSH header in a way that it expire 706 at the relevant SF. How the initiator gets the Discriminator value 707 of the SF is outside the scope of this document. 709 6.4.3. In-Situ OAM 711 [I-D.ietf-sfc-ioam-nsh] defines how In-Situ OAM data fields are 712 transported using NSH header. [I-D.ietf-sfc-proof-of-transit] 713 defines a mechanism to perform proof of transit to securely verify if 714 a packet traversed the relevant SFP or SFC. While the mechanism is 715 defined inband (i.e., it will be included in data packets), it may be 716 used to perform various SFC OAM functions as well. 718 In-Situ OAM could be used with O bit set to perform SF availability 719 and SFC availability or performance measurement. 721 6.4.4. SFC Traceroute 723 [I-D.penno-sfc-trace] defines a protocol that checks for path 724 liveliness and traces the service hops in any SFP. Section 3 of 725 [I-D.penno-sfc-trace] defines the SFC trace packet format while 726 Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF 727 and SFF respectively. While [I-D.penno-sfc-trace] has expired, the 728 proposal is implemented in Open Daylight and available. 730 An initiator can control the Service Index Limit (SIL) in SFC trace 731 packet to perform SF and SFC availability test. 733 7. Manageability Considerations 735 This document does not define any new manageability tools but 736 consolidates the manageability tool gap analysis for SF and SFC. 738 Table 4: OAM Tool GAP Analysis 739 +----------------+--------------+-------------+--------+-------------+ 740 | Layer |Configuration |Orchestration|Topology|Notification | 741 +----------------+--------------+-------------+--------+-------------+ 742 | Underlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog,| 743 | | | | |NETCONF | 744 +----------------+--------------+-------------+--------+-------------+ 745 | Overlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog | 746 | | | | |NETCONF | 747 +----------------+--------------+-------------+--------+-------------+ 748 | Classifier | CLI, NETCONF | CLI, NETCONF| None | None | 749 +----------------+--------------+-------------+--------+-------------+ 750 | SF |CLI, NETCONF | CLI, NETCONF| None | None | 751 +----------------+--------------+-------------+--------+-------------+ 752 | SFC |CLI, NETCONF | CLI, NETCONF| None | None | 753 +----------------+--------------+-------------+--------+-------------+ 754 Configuration, orchestration and manageability of SF and SFC could be 755 performed using CLI, NETCONF, etc. 757 As depicted in Table 4, information and data models are needed for 758 configuration, manageability and orchestration for SFC. With 759 virtualized SF and SFC, manageability needs to be done 760 programmatically. 762 8. Security Considerations 764 Any security consideration defined in [RFC7665] and [RFC8300] are 765 applicable for this document. 767 The OAM information from service layer at different components may 768 collectively or independently reveal sensitive information. The 769 information may reveal the type of service functions hosted in the 770 network, the classification rules and the associated service chains, 771 specific service function paths etc. The sensitivity of the 772 information from SFC layer raises a need for careful security 773 considerations 775 The mapping and the rules information at the classifier component may 776 reveal the traffic rules and the traffic mapped to the SFC. The SFC 777 information collected at an SFC component may reveal the SF 778 associated within each chain and this information together with 779 classifier rules may be used to manipulate the header of synthetic 780 attack packets that may be used to bypass the SFC and trigger any 781 internal attacks. 783 The SF information at the SF component may be used by a malicious 784 user to trigger Denial of Service (DoS) attack by overloading any 785 specific SF using rogue OAM traffic. 787 To address the above concerns, SFC and SF OAM may provide mechanism 788 for: 790 o Misuse of the OAM channel for denial-of-services, 792 o Leakage of OAM packets across SFC instances, and 794 o Leakage of SFC information beyond the SFC domain. 796 The documents proposing the OAM solution for SF component should 797 consider rate-limiting the OAM probes at a frequency guided by the 798 implementation choice. Rate-limiting may be applied at the SFF or 799 the SF . The OAM initiator may not receive a response for the probes 800 that are rate-limited resulting in false negatives and the 801 implementation should be aware of this. 803 The documents proposing the OAM solution for any service layer 804 components should consider some form of message filtering to prevent 805 leaking any internal service layer information outside the 806 administrative domain. 808 9. IANA Considerations 810 No action is required by IANA for this document. 812 10. Acknowledgements 814 We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky 815 and Tal Mizrahi for their review and comments. 817 11. Contributing Authors 819 Nobo Akiya 820 Ericsson 821 Email: nobo.akiya.dev@gmail.com 823 12. References 825 12.1. Normative References 827 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 828 Requirement Levels", BCP 14, RFC 2119, 829 DOI 10.17487/RFC2119, March 1997, 830 . 832 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 833 Chaining (SFC) Architecture", RFC 7665, 834 DOI 10.17487/RFC7665, October 2015, 835 . 837 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 838 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 839 May 2017, . 841 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 842 "Network Service Header (NSH)", RFC 8300, 843 DOI 10.17487/RFC8300, January 2018, 844 . 846 12.2. Informative References 848 [I-D.ietf-sfc-ioam-nsh] 849 Brockners, F. and S. Bhandari, "Network Service Header 850 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 851 ietf-sfc-ioam-nsh-02 (work in progress), September 2019. 853 [I-D.ietf-sfc-proof-of-transit] 854 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 855 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 856 transit-03 (work in progress), September 2019. 858 [I-D.penno-sfc-trace] 859 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 860 "Services Function Chaining Traceroute", draft-penno-sfc- 861 trace-03 (work in progress), September 2015. 863 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 864 RFC 792, DOI 10.17487/RFC0792, September 1981, 865 . 867 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 868 Metric for IP Performance Metrics (IPPM)", RFC 3393, 869 DOI 10.17487/RFC3393, November 2002, 870 . 872 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 873 Control Message Protocol (ICMPv6) for the Internet 874 Protocol Version 6 (IPv6) Specification", STD 89, 875 RFC 4443, DOI 10.17487/RFC4443, March 2006, 876 . 878 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 879 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 880 . 882 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 883 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 884 DOI 10.17487/RFC5881, June 2010, 885 . 887 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 888 "Bidirectional Forwarding Detection (BFD) for MPLS Label 889 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 890 June 2010, . 892 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 893 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 894 Acronym in the IETF", BCP 161, RFC 6291, 895 DOI 10.17487/RFC6291, June 2011, 896 . 898 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 899 Service Function Chaining", RFC 7498, 900 DOI 10.17487/RFC7498, April 2015, 901 . 903 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 904 Ed., "A One-Way Delay Metric for IP Performance Metrics 905 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 906 2016, . 908 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 909 Ed., "A One-Way Loss Metric for IP Performance Metrics 910 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 911 2016, . 913 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 914 Pallagatti, "Seamless Bidirectional Forwarding Detection 915 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 916 . 918 [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless 919 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, 920 and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, 921 . 923 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 924 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 925 Switched (MPLS) Data-Plane Failures", RFC 8029, 926 DOI 10.17487/RFC8029, March 2017, 927 . 929 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 930 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 931 DOI 10.17487/RFC8459, September 2018, 932 . 934 Authors' Addresses 936 Sam K. Aldrin 937 Google 939 Email: aldrin.ietf@gmail.com 940 Carlos Pignataro (editor) 941 Cisco Systems, Inc. 943 Email: cpignata@cisco.com 945 Nagendra Kumar (editor) 946 Cisco Systems, Inc. 948 Email: naikumar@cisco.com 950 Ram Krishnan 951 VMware 953 Email: ramkri123@gmail.com 955 Anoop Ghanwani 956 Dell 958 Email: anoop@alumni.duke.edu