idnits 2.17.1 draft-lm-mpls-sfc-path-verification-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 152: '... nodes MUST ignore the TLV and proce...' RFC 2119 keyword, line 168: '... Sub-TLV, as defined in Figure 3, MUST...' RFC 2119 keyword, line 173: '...ion request, the SFF MUST respond with...' RFC 2119 keyword, line 300: '... SFF MUST parse through the label st...' RFC 2119 keyword, line 329: '... MUST discard any packets with TTL s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2020) is 1381 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7665' is defined on line 368, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-15 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Y. Liu 3 Internet-Draft G. Mirsky 4 Intended status: Standards Track ZTE Corporation 5 Expires: January 13, 2021 July 12, 2020 7 MPLS-based Service Function Path(SFP) Consistency Verification 8 draft-lm-mpls-sfc-path-verification-00 10 Abstract 12 This document proposes a method to verify the correlation between 13 Service Function Chaining control and/or management plane view of the 14 specified Service Function Path and the state of its data. It works 15 for both SR service programming and MPLS-based NSH SFC. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 13, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions used in this document . . . . . . . . . . . . . . 2 53 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. MPLS-based SFP Consistency Verification . . . . . . . . . . . 3 55 3.1. MPLS-based SFP Consistency Verification . . . . . . . . . 4 56 3.2. SFC Info Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 57 3.3. SFC Basic Unit FEC Sub-TLV . . . . . . . . . . . . . . . 6 58 3.4. Theory of Operation . . . . . . . . . . . . . . . . . . . 6 59 3.4.1. MPLS-based service programming . . . . . . . . . . . 7 60 3.4.2. RFC 8595 path consistency . . . . . . . . . . . . . . 7 61 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 62 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 4.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 Service Function Chain (SFC) defines an ordered set of service 70 functions (SFs) to be applied to packets and/or frames, and/or flows 71 selected as a result of classification. 73 SFC can be achieved through a variety of encapsulation methods, such 74 as NSH [RFC8300], SR service programming 75 [I-D.ietf-spring-sr-service-programming] and MPLS-based NSH SFC 76 [RFC8595]. 78 This document describes extensions to MPLS LSP ping [RFC8029] 79 mechanisms to support verification between the control/management 80 plane and the data plane state for both SR-MPLS service programming 81 and MPLS-based NSH SFC. 83 2. Conventions used in this document 85 2.1. Acronyms 87 SFC: Service Function Chain 89 SFF: Service Function Forwarder 91 SF: Service Function 93 SFP: Service Function Path 95 RSP: Rendered Service Path 97 3. MPLS-based SFP Consistency Verification 99 MPLS echo request and reply messages [RFC8029] can be extended to 100 support the verification of the consistency of an MPLS-based Service 101 Function Path (SFP). 103 SR-MPLS/MPLS can be used to realize an SFP. Two methods have been 104 defined: 106 o [I-D.ietf-spring-sr-service-programming] describes how to achieve 107 service function chaining in SR-enabled MPLS and IPv6 networks. 108 In an SR-MPLS network, each SF is associated with an MPLS label. 109 As a result, an SFP can be encoded as a stack of MPLS labels and 110 pushed on top of the packet. 112 o [RFC8595] provides another method to realize SFC in an MPLS 113 network by means of using a logical representation of the Network 114 Service Header (NSH) in an MPLS label stack. When an MPLS label 115 stack is used to carry a logical NSH, a basic unit of 116 representation is used, which can be present one or more times in 117 the label stack. This unit comprises two MPLS labels, one carries 118 a label to provide a context within the SFC scope (the SFC Context 119 Label), and the other carries a label to show which SF is to be 120 enacted (the SF Label). This two-label unit is shown in Figure 1. 122 0 1 2 3 123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | SFC Context Label | TC |S| TTL | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | SF Label | TC |S| TTL | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 1: The Basic Unit of MPLS Label Stack for SFC 132 In MPLS Label Switched Paths (LSPs), MPLS LSP ping [RFC8029] is used 133 to check the correctness of the data plane functioning and to verify 134 the data plane against the control plane. 136 The proposed extension of MPLS LSP ping allows verification of the 137 correlation between the control/management (if data model-based 138 central controller used) plane and the data plane state in SR-MPLS/ 139 MPLS-based SFC. 141 Generally, except for the designed specific functions, the packet 142 processing functions supported by SFs are limited. SFs may not 143 support MPLS OAM protocols like LSP ping, so SFFs are responsible for 144 MPLS echo request processing. 146 3.1. MPLS-based SFP Consistency Verification 148 An MPLS SFC validation request/reply is an MPLS echo request/reply 149 that includes an SFC validation TLV. 151 Nodes examine and process the TLV only if configured to do so; other 152 nodes MUST ignore the TLV and process the packet as a standard MPLS 153 echo packet. 155 0 1 2 3 156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | TLV Type=TBA1 | Length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 | SFC Information Sub-TLV(s) | 162 ~ ~ 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 2: SFC Validation TLV 168 SFC Information Sub-TLV: The Sub-TLV, as defined in Figure 3, MUST 169 NOT be included in an MPLS SFC validation request. 171 3.2. SFC Info Sub-TLV 173 Upon receiving the SFC validation request, the SFF MUST respond with 174 an echo reply, which includes the SFC detailed information. 176 The SFC detailed information is recorded in SFC info sub-TLV. 178 Two types of sub-TLVs are defined in this section, and those are used 179 in MPLS-based service programming 180 [I-D.ietf-spring-sr-service-programming] and MPLS-based NSH [RFC8595] 181 respectively. 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | sub-TLV Type=TBA1 | Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | SFF Label | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | SF Label | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | SF Type | SR Proxy Type | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 3: SFC Info Sub-TLV for SR-MPLS-based Service Programming 197 Type TBA1 sub-TLV: used in SR-MPLS-based service programming 199 SFF Label: represents the SID of the SFF 201 SF Label: represents the service SID of the SF or SR proxy 203 SF Type: indicates the type of SF, such as DPI, firewall, etc. 205 SR Proxy Type: It is defined in 206 [I-D.ietf-spring-sr-service-programming] and indicates the type of SR 207 proxy if it exists. 209 0 1 2 3 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | sub-TLV Type=TBA2 | Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | SFC-FWD Type | Reserved | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | SFC context Label | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | SF Label | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | SF Type | Reserved | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 4: SFC Info Sub-TLV for MPLS-based NSH 225 Type TBA2 sub-TLV: used in MPLS-based NS 227 SFC-FWD Type: indicates the forwarding type of the data plane, and 228 has the following values: 230 0x10: MPLS-based NSH [RFC8595] label swapping 231 0x11: MPLS-based NSH [RFC8595] label stacking 233 SFC context Label: The meaning of the SFC context label depends on 234 the SFC Type. If SFC-FWD Type is 0x10, the SFC context Label 235 represents SPI. If SFC-FWD Type is 0x11, the SFC context Label 236 represents the context label [RFC8595]. 238 SF Label: The meaning of the SF label depends on the SFC-FWD Type. 239 If SFC Type is 0x10, the SF Label represents SI. If SFC Type is 240 0x11, the SF Label represents the SFI index [RFC8595]. 242 SF Type: It is defined in [I-D.ietf-bess-nsh-bgp-control-plane] and 243 indicates the type of SF, such as DPI, firewall, etc. 245 3.3. SFC Basic Unit FEC Sub-TLV 247 Unlike standard MPLS forwarding, which is based on a single label, in 248 [RFC8595], packet forwarding is based on the basic unit of MPLS label 249 stack for SFC(SFC Context Label+SF Label). A new FEC sub-TLV is 250 defined in this document, which can be used to carry the 251 corresponding FEC of the basic unit. 253 0 1 2 3 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Route Distinguisher (RD) | 257 | (8 octets) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | SF Type | Reserved | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 5: SFC Basic Unit sub-TLV 264 Route Distinguisher (RD): 8 octets field in SFIR Route Type specific 265 NLRI [I-D.ietf-bess-nsh-bgp-control-plane] . 267 SF Type: 2 octets. It is defined in [I-D.ietf-bess-nsh-bgp-control- 268 plane] and indicates the type of SF, such as DPI, firewall, etc. 270 A node that receives an LSP ping with the new FEC will check if it is 271 its Route Distinguisher and whether it advertised that Service 272 Function Type. 274 3.4. Theory of Operation 276 An MPLS SFC validation request is an MPLS echo request with an SFC 277 validation TLV, and the echo request is sent with a label stack 278 corresponding to the SFP being tested. 280 Sending an SFC echo request to the control plane is triggered by one 281 of the following packet processing exceptions: IP TTL expiration, 282 MPLS TTL expiration, or the receiver is the terminal SFF for an SFP. 284 After general packet sanity verifying[RFC8029], section 3.4.1 and 285 section 3.4.2 in this document separately describe the following 286 processing procedures in service programming and MPLS-based NSH. 288 After all SFFs on the SFP send back MPLS echo reply, the sender 289 collects information about all traversed SFFs and SFs on the rendered 290 service path (RSP). 292 3.4.1. MPLS-based service programming 294 [I-D.ietf-spring-sr-service-programming] describes how a service can 295 be associated with a SID to achieve service function chaining. In an 296 SR-MPLS network, the SFP is encoded as a stack of MPLS labels. That 297 stack is pushed on top of the packet. 299 If an SFC validation TLV is present in the received echo request, an 300 SFF MUST parse through the label stack until the next label is not a 301 local service SID to get all the SFs attached to the SFF on the SFP 302 and record the corresponding Label-stack-depth. 304 The SFF then sends an MPLS echo reply with all the SF information 305 recorded in SFC Information Sub-TLV, including the service SID and 306 the SF type. 308 3.4.2. RFC 8595 path consistency 310 [RFC8595] describes how Service Function Chaining (SFC) can be 311 achieved in an MPLS network using a logical representation of the 312 Network Service Header (NSH) in an MPLS label stack. 314 SFC forwarding can be achieved by label swapping, label stacking, or 315 the mix of both. When an SFF receives a packet containing an MPLS 316 label stack, it examines the top basic unit of MPLS label stack for 317 SFC, {SPI, SI} or {context label, SFI index}, to determine where to 318 send the packet next. 320 Upon receiving the SFC validation request, an SFF checks the MPLS 321 label stack to get all the locally attached basic units for SFC. 322 Then, the SFF sends back a reply message, including SFC info sub- 323 TLVs, for each basic unit local to the SFF. 325 3.5. Discussion 327 In [RFC8595], it says, "when an SFF receives a packet from any 328 component of the SFC system (classifier, SFI, or another SFF), it 329 MUST discard any packets with TTL set to zero". To trace SFC, it 330 should be changed to allow punting the packet to the control plane 331 though under throttling control. 333 4. References 335 4.1. Normative References 337 [I-D.ietf-bess-nsh-bgp-control-plane] 338 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 339 Jalil, "BGP Control Plane for the Network Service Header 340 in Service Function Chaining", draft-ietf-bess-nsh-bgp- 341 control-plane-15 (work in progress), June 2020. 343 [I-D.ietf-spring-sr-service-programming] 344 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 345 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 346 Henderickx, W., and S. Salsano, "Service Programming with 347 Segment Routing", draft-ietf-spring-sr-service- 348 programming-02 (work in progress), March 2020. 350 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 351 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 352 Switched (MPLS) Data-Plane Failures", RFC 8029, 353 DOI 10.17487/RFC8029, March 2017, 354 . 356 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 357 "Network Service Header (NSH)", RFC 8300, 358 DOI 10.17487/RFC8300, January 2018, 359 . 361 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 362 Forwarding Plane for Service Function Chaining", RFC 8595, 363 DOI 10.17487/RFC8595, June 2019, 364 . 366 4.2. Informative References 368 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 369 Chaining (SFC) Architecture", RFC 7665, 370 DOI 10.17487/RFC7665, October 2015, 371 . 373 Authors' Addresses 375 Liu Yao 376 ZTE Corporation 377 No. 50 Software Ave, Yuhuatai Distinct 378 Nanjing 379 China 381 Email: liu.yao71@zte.com.cn 383 Greg Mirsky 384 ZTE Corporation 386 Email: gregimirsky@gmail.com