idnits 2.17.1 draft-dolson-sfc-oam-sff-sf-cv-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 19, 2016) is 2837 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 241, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ooamdt-rtgwg-demand-cc-cv-00 == Outdated reference: A later version (-04) exists of draft-ooamdt-rtgwg-ooam-header-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Dolson 3 Internet-Draft K. Larose 4 Intended status: Informational Sandvine 5 Expires: January 20, 2017 July 19, 2016 7 OAM Mechanism for SFF-SF Connectivity Verification 8 draft-dolson-sfc-oam-sff-sf-cv-01 10 Abstract 12 This document describes a mechanism and packet format for allowing a 13 Service Function Forwarder (SFF) to verify connectivity of an 14 connected SFF or Service Function (SF). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 20, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. SFF-SF Connectivity Verification . . . . . . . . . . . . . . 2 52 3. Echo Request Responder Behavior . . . . . . . . . . . . . . . 4 53 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 59 1. Introduction 61 As described in Service Function Chaining (SFC) Architecture 62 [RFC7665], Service Function Forwarders (SFFs) are responsible for 63 forwarding traffic to connected Service Functions (SFs). 65 We believe there is a need for the SFFs to monitor connectivity to 66 the SFs at the NSH layer. Rather than have the SFFs simply ping each 67 SF's IP stack, we believe it is important to test NSH connectivity 68 because the two protocols (IP and NSH) are often handled by different 69 hardware or code modules. 71 As an example, an SFF may wish to health-check multiple connected SFs 72 prior to load-balancing NSH traffic to the SFs, having the means to 73 automatically remove unreachable SFs from service. 75 This document proposes an NSH OAM format allowing an SFF to request a 76 neighboring SF to respond to an echo request via NSH encapsulation. 77 This format can also be used for an SFF to request an neighboring SFF 78 to respond to an echo request. 80 Note that this connectivity checking is NOT to be confused with path 81 verification. It is in fact a feature of this mechanism that no path 82 forwarding needs to be configured to perform the connectivity 83 verification. 85 This document proposes use of the format of continuity check proposed 86 in [I-D.ooamdt-rtgwg-demand-cc-cv] to be used within NSH frames for 87 SFF-to-SF connectivity verification. 89 2. SFF-SF Connectivity Verification 91 An SFF may determine connectivity to an SF by means of echo request/ 92 response. However, any two NSH nodes could verify connectivity by 93 the following mechanism. 95 By embedding the overlay ping packet format 96 [I-D.ooamdt-rtgwg-demand-cc-cv] within the OAM header 97 [I-D.ooamdt-rtgwg-ooam-header] in NSH, the packet format is that of 98 Figure 1. The MD-type 2 is shown, since no metadata is required. 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 102 |Ver|O|C|R|R|R|R|R|R| Length=2 | MD-type=0x2 | OAM Proto=TBA1| | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSH 104 | Service Path ID=0xffffff | SI=0xff | / 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 106 | V | Msg Type | Flags | Length | | OAM 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 108 | Version Number | Global Flags | \ 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 110 | Message Type | Reply mode | Return Code | Return S.code | | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM 112 | Sender's Handle | | Ping 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 114 | Sequence Number | | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 116 | TLVs | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 119 Figure 1: OAM Ping Encapsulated within NSH 121 The fields are: 123 Length: Header length in words 125 MD-type: metadata type of 2 is used because no metadata is 126 required. 128 OAM Protocol: a value of TBA1 indicates the NSH header is followed 129 by an OAM Header. 131 Service Path ID: Should be set by sender to 0xffffff. Receiver 132 should ignore it. 134 Service Index: Should be set by sender to 255. Receiver should 135 ignore it. 137 V: OAM header version should be set by sender to 0 (?) 139 Msg Type: value ? indicates OAM ping message follows the OAM 140 header. 142 Flags: Value 0, indicating no extensions to the OAM header 143 [I-D.ooamdt-rtgwg-ooam-header]. 145 Length: Length of the OAM Ping portion of the message 146 [I-D.ooamdt-rtgwg-ooam-header]. 148 Version Number: refer to [I-D.ooamdt-rtgwg-demand-cc-cv] 150 Global Flags: refer to [I-D.ooamdt-rtgwg-demand-cc-cv] 152 Message Type: Initiator (SFF) is to use the code for "Overlay Echo 153 Request" and responder (SF) is to use the code for "Overlay Echo 154 Reply" [I-D.ooamdt-rtgwg-demand-cc-cv] 156 Reply Mode: code for "Reply to Sender" 157 [I-D.ooamdt-rtgwg-demand-cc-cv] (requires extension) 159 Return Code: Unused at this time. MUST be ignored by initiator 160 and responder. 162 Return Subcode: Unused at this time. MUST be ignored by initiator 163 and responder. 165 Sender's Handle: an arbitrary handle chosen by the initiator, to 166 be echoed by the responder. This value is generally constant 167 across requests and may be useful for identifying the initiator in 168 a debugging situation. 170 Sequence Number: a number chosen by the initiator, to be echoed by 171 the responder. This value is generally incremeted by 1 between 172 requests and may be useful for debugging packet loss counts. 174 TLVs: The initiator may place any TLVs. The responder MUST echo 175 back the TLVs verbatim unless TLVs are specifically defined 176 otherwise. No OAM TLVs are required for this connectivity 177 verification. However, (a) timestamp TLVs are expected to be 178 useful for the sender to measure round-trip time; (b) large 179 padding TLVs are expected to be useful for verifying MTU of a 180 connection. 182 3. Echo Request Responder Behavior 184 An NSH node receiving an echo request MUST do the following: 186 1. Clone the NSH packet and contents verbatim 188 2. Change the Message Type from "Overlay Echo Request" to "Overlay 189 Echo Reply" [I-D.ooamdt-rtgwg-demand-cc-cv] 191 3. Send the NSH packet back to the initiator using the transport the 192 echo request was received on. 194 Note that for this type of OAM packet, the NSH packet is NOT 195 forwarded according to path ID and service index, rather MUST be 196 returned to the immediate peer. The echo is expected to work even 197 when SFF forwarding tables are empty or incomplete. 199 For example, an NSH packet transported directly over Ethernet MUST be 200 returned to the MAC address from which it was received. As another 201 example, an NSH packet received over UDP MUST be returned to the IP 202 address and UDP port the were the source address and ports of the 203 request. 205 It might not be possible to use this OAM packet if there is not an 206 obvious way to return the packet to the sender. 208 4. Acknowledgements 210 Thanks to the Overlay OAM Design team and authors of 211 [I-D.ooamdt-rtgwg-demand-cc-cv] for pointing us an approach in common 212 with other overlays. 214 5. IANA Considerations 216 TODO: Need to request any codes, subcodes or TLVs? 218 6. Security Considerations 220 To reduce any attack surface, the initiator should verify that the 221 received echo response is a response to the echo request it sent by 222 comparing the handle and sequence number fields. 224 7. Normative References 226 [I-D.ooamdt-rtgwg-demand-cc-cv] 227 Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar, 228 D., Chen, M., Yizhou, L., Mozes, D., and i. 229 ibagdona@gmail.com, "On-demand Continuity Check (CC) and 230 Connectivity Verification(CV) for Overlay Networks", 231 draft-ooamdt-rtgwg-demand-cc-cv-00 (work in progress), 232 July 2016. 234 [I-D.ooamdt-rtgwg-ooam-header] 235 Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar, 236 D., Chen, M., Yizhou, L., Mozes, D., and i. 237 ibagdona@gmail.com, "OAM Header for use in Overlay 238 Networks", draft-ooamdt-rtgwg-ooam-header-00 (work in 239 progress), July 2016. 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, 243 DOI 10.17487/RFC2119, March 1997, 244 . 246 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 247 Chaining (SFC) Architecture", RFC 7665, 248 DOI 10.17487/RFC7665, October 2015, 249 . 251 Authors' Addresses 253 David Dolson 254 Sandvine 255 408 Albert Street 256 Waterloo, ON N2L 3V3 257 Canada 259 Phone: +1 519 880 2400 260 Email: ddolson@sandvine.com 262 Kyle Larose 263 Sandvine 264 408 Albert Street 265 Waterloo, ON N2L 3V3 266 Canada 268 Phone: +1 519 880 2400 269 Email: klarose@sandvine.com