idnits 2.17.1 draft-krishnan-sfc-oam-req-framework-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'STEALTH FIREWALL' is defined on line 264, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SFC Working Group R. Krishnan 2 Internet Draft Brocade 3 Category: Informational A. Ghanwani 4 Dell 5 Pedro A. Aranda Gutierrez 6 D. R. Lopez 7 Telefonica I+D 8 J. Halpern 9 S. Kini 10 Ericsson 11 Andy Reid 12 BT 14 Expires: October 2014 July 3, 2014 16 SFC OAM Requirements and Framework 18 draft-krishnan-sfc-oam-req-framework-00 20 Abstract 22 This document discusses SFC OAM requirements and proposes a SFC OAM 23 Framework to handle these requirements. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with 28 the provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on April, 2014. 48 Copyright Notice 50 Copyright (c) 2014 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 (http://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 58 respect to this document. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 [RFC 2119]. 66 Table of Contents 68 1. Introduction...................................................3 69 1.1. Acronyms..................................................4 70 2. SFC OAM Requirements...........................................4 71 2.1. Topologies................................................4 72 2.2. Connectivity..............................................4 73 2.2.1. Connectivity Check...................................4 74 2.2.2. SFP Trace............................................5 75 2.3. Performance...............................................5 76 2.4. Leakage of OAM Messages...................................5 77 2.5. Appliance Types...........................................5 78 3. IANA Considerations............................................6 79 4. Security Considerations........................................6 80 5. Acknowledgements...............................................6 81 6. References.....................................................6 82 6.1. Normative References......................................6 83 6.2. Informative References....................................6 84 Authors' Addresses................................................7 86 1. Introduction 88 Operations, administration, and maintenance (OAM) is the general 89 term applied to monitoring both the connectivity and performance in 90 the network [RFC 6291] [RFC 7276]. The goal of SFC OAM then is to 91 monitor these attributes for a service function chain (SFC). 93 Some clarification is needed regarding the scope of this work. SFC 94 OAM does will not attempt to monitor the actual services. Also, SFC 95 OAM does not replace or obviate the need for transport-level OAM 96 functions such as NVO3 OAM, IEEE 802.1ag, MPLS OAM, or whatever else 97 may be applicable depending on the network technology that the SFC 98 is implemented on. 100 The following figure depicts the layering of OAM. 102 +--+ +-+ +-+ +--+ +-+ +-+ +--+ +---+ +-+ +-+ +---+ +--+ +-+ +--+ 103 |ES|-|B|-|B|-|SF|-|R|-|R|-|SF|-|NVE|-|B|-|B|-|NVE|-|SF|-|B|-|ES| 104 +--+ +-+ +-+ +--+ +-+ +-+ +--+ +---+ +-+ +-+ +---+ +--+ +-+ +--+ 106 X------------------------------------------------------------X (APP) 107 x------------o-------------------------o (SFC) 108 x-------------x (NVO3) 109 x---x (L3/MPLS) 110 x---x x---x (L2) 112 ES: End Station 113 B: IEEE 802.1Q Bridge 114 R: Router or LSR 115 NVE: Network Virtualization Edge 116 SF: Service function (or SFF) 117 X: Maintenance End Point (MEP) 118 O: Maintenance Intermediate Point (MIP) 120 Figure 1: Layered OAM Architecture 122 The SFC layer resides above the transport layer (where the transport 123 layer can simply be implemented using VLANs or may be done using 124 overlays such as VXLAN or NVGRE), and below the application layer 125 (APP). As mentioned earlier, depending on the underlying network 126 technology, other OAM layers may be present (NVO3 OAM [NVO3 OAM], 127 L3/MPLS OAM [RFC 7276], IEEE 802.1ag CFM [IEEE 802.1ag], etc.). The 128 use of the terms maintenance end point (MEP) and maintenance (MIP) 129 are consistent with IEEE 802.1Q are simply used to denote points 130 where monitoring services are configured. 132 The systems denoted SF refer to devices in the network that either 133 insert, modify, remove, or access the service chain header (SCH) 134 [SCH draft]. These nodes may implement the actual service function 135 (as would be the case for an SF-aware appliance) or they may be 136 proxy nodes such as SFFs with the service function itself residing 137 in a different device (as would be the case for an SF-unaware 138 appliance). 140 1.1. Acronyms 142 DPI: Deep Packet Inspection 144 MPLS: Multiprotocol Label Switching 146 NVGRE: Network Virtualization using Generic Routing Encapsulation 148 OAM: Operations, Administration, and Maintenance 150 SF: Service Function 152 SFC: Service Function Chain 154 SFP: Service Function Path 156 VXLAN: Virtual Extensible LAN 158 2. SFC OAM Requirements 160 2.1. Topologies 162 Mechanisms must be provided to monitor the entire SFP or just a 163 portion of the SFP. 165 SFC OAM must also be able to handle various topologies that can be 166 created such a point-to-point or multipoint. 168 2.2. Connectivity 170 2.2.1. Connectivity Check 172 The purpose of the connectivity check tool is to test the liveness 173 of a given service function along a given SFP (service function 174 path). 176 Mechanisms must be provided so that the SFC OAM messages may be sent 177 along the same path that a given data packet would follow. In other 178 words, it should be possible to construct SFC OAM packets that would 179 be treated by network devices such as bridges and routers as they 180 would handle regular data packets on that SFP from the standpoint of 181 functions such as link aggregation and equal cost multipath. 183 2.2.2. SFP Trace 185 The purpose of SFP trace is to provide the list of SFs that comprise 186 the service function chain as defined by the SCH. 188 Mechanisms must be provided so that the SFC OAM messages may be sent 189 along the same path that a given data packet would follow. In other 190 words, it should be possible to construct SFC OAM packets that would 191 be treated by network devices such as bridges and routers as they 192 would handle regular data packets on that SFP from the standpoint of 193 functions such as link aggregation and equal cost multipath. 195 2.3. Performance 197 It must be possible to measure various parameters of a given SFP 198 such as the loss, delay, and delay variation through the service 199 chain. 201 [ Ed Note: Details TBD ] 203 2.4. Leakage of OAM Messages 205 Mechanisms must be provided to ensure that OAM messages are received 206 only by devices that need to process them. These messages must 207 never be forwarded to devices that would terminate such messages as 208 result of not knowing how to process them. 210 2.5. Appliance Types 212 SFC OAM must provide tools that operate through various types of 213 appliances including: 215 . Transparent appliances: These appliances typically do not make 216 any modifications to the packet. In such cases, the SFF may be 217 able to process OAM messages. 219 . Appliances that modify the packet: These appliances modify 220 packet fields. Certain appliances may modify only the headers 221 corresponding to the network over which it is transported, e.g. 222 the MAC headers or overlay headers. In other cases, the IP 223 header of the application's packet may be modified, e.g. NAT. 224 In yet other cases, the application session itself may be 225 terminated and a new session initiated, e.g. a load balancer 226 that offers HTTPS termination. 228 In general, it should be possible to allow or disallow having a 229 given SF operate on an OAM packet in the same way that it would on 230 a regular data packet, but with the awareness that it is operating 231 on an OAM packet. It is essential to recognize the OAM message so 232 that its status (as an OAM message) can be preserved as it is 233 processed through the normal data path. 235 3. IANA Considerations 237 This draft does not have any IANA considerations. 239 4. Security Considerations 241 TBD 243 5. Acknowledgements 245 6. References 247 6.1. Normative References 249 6.2. Informative References 251 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels," March 1997. 254 [RFC 6291] Andersson, L. et al., "Guidelines for the Use of the 255 "OAM" Acronym in the IETF," June 2011 257 [RFC 7276] Mizrahi, T. et al., "An Overview of Operations, 258 Administration, and Maintenance (OAM) Tools," June 2014 260 [NVO3 OAM] Senevirathne, T., "NVO3 Fault Management," 261 https://datatracker.ietf.org/doc/draft-tissa-nvo3-oam- 262 fm/?include_text=1, August 2014 264 [STEALTH FIREWALL] Brandon Gillespie "Stealth firewalls", 265 http://www.giac.org/paper/gsec/629/stealth-firewalls/101440 267 [SCH draft] Quinn, P. et al., "Network Service Header," 268 https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/, February 2014 270 Authors' Addresses 272 Ram Krishnan 273 Brocade Communications 274 ramk@brocade.com 276 Anoop Ghanwani 277 Dell 278 anoop@alumni.duke.edu 280 Pedro A. Aranda Gutierrez 281 Telefonica I+D 282 Don Ramon de la Cruz, 82 283 Madrid, 28006, Spain 284 +34 913 129 041 285 pedroa.aranda@tid.es 287 Diego Lopez 288 Telefonica I+D 289 Don Ramon de la Cruz, 82 290 Madrid, 28006, Spain 291 +34 913 129 041 292 diego@tid.es 294 Joel Halpern 295 Ericsson 296 joel.halpern@ericsson.com 298 Sriganesh Kini 299 Ericsson 300 Sriganesh.kini@ericsson.com 302 Andy Reid 303 BT 304 andy.bd.reid@bt.com