idnits 2.17.1 draft-scharf-tcpm-yang-tcp-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-netconf-tcp-client-server]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 7, 2019) is 1752 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) == Outdated reference: A later version (-26) exists of draft-ietf-netconf-tcp-client-server-02 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-06 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM M. Scharf 3 Internet-Draft Hochschule Esslingen 4 Intended status: Standards Track V. Murgai 5 Expires: January 8, 2020 Cisco Systems Inc 6 July 7, 2019 8 YANG Groupings for Transmission Control Protocol (TCP) Configuration 9 draft-scharf-tcpm-yang-tcp-02 11 Abstract 13 This document specifies a YANG model for TCP on devices that are 14 configured by network management protocols. The YANG model defines 15 groupings for fundamental parameters that can be modified in many TCP 16 implementations. The model extends a base model for TCP clients and 17 servers [I-D.ietf-netconf-tcp-client-server]. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 8, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Model Overview . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Modeling Scope . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Basic TCP Configuration Parameters . . . . . . . . . . . 5 58 3.3. Model Design . . . . . . . . . . . . . . . . . . . . . . 6 59 3.4. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 60 4. TCP Configuration YANG Model . . . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 7.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 67 Appendix B. Changes compared to previous versions . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 The Transmission Control Protocol (TCP) [RFC0793] is used by many 73 applications in the Internet, including control and management 74 protocols. Therefore, TCP is implemented on network elements that 75 can be configured via network management protocols such as NETCONF 76 [RFC6241] or RESTCONF [RFC8040]. This document specifies a YANG 77 model [RFC6020][RFC7950] for configuring TCP on network elements that 78 support YANG data models. This document extends a base model for TCP 79 clients and servers [I-D.ietf-netconf-tcp-client-server]. The model 80 focuses on fundamental and standard TCP functions that are widely 81 implemented. The model can be augmented to address more advanced or 82 implementation-specific TCP features. Operational state and 83 statistics are outside the scope of this memo. 85 Many protocol stacks on Internet hosts use other methods to configure 86 TCP, such as operating system configuration or policies. Many TCP/IP 87 stacks cannot be configured by network management protocols such as 88 NETCONF or RESTCONF and they do not use YANG data models. Yet, such 89 TCP implementations often also have means to configure the parameters 90 listed in this document. All parameters defined in this document are 91 optional. 93 This specification is orthogonal to a Management Information Base 94 (MIB) for the Transmission Control Protocol (TCP) that has been 95 standardized [RFC4022]. A MIB providing extended statistics for TCP 96 is also available [RFC4898], and there are also MIBs for UDP 97 [RFC4113] and SCTP [RFC3873]. It is possible to translate a MIB into 98 a YANG model, for instance using the translation described in 99 [RFC6643]. However, this approach is not used in this document, as 100 such a translated model would not be up-to-date. 102 There are also other related YANG models. Examples are: 104 o Application protocol models may include TCP parameters, for 105 example in case of BGP [I-D.ietf-idr-bgp-model]. 107 o TCP header attributes are modeled in other models, such as 108 [I-D.ietf-netmod-acl-model]. 110 o TCP-related configuration of a NAT is defined in 111 [I-D.ietf-opsawg-nat-yang]. 113 2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. Model Overview 123 3.1. Modeling Scope 125 TCP is implemented on many different system architectures. As a 126 result, there are may different and often implementation-specific 127 ways to configure parameters of the TCP protocol engine. In 128 addition, in many TCP/IP stacks configuration exists for different 129 scopes: 131 o Global configuration: Many TCP implementations have configuration 132 parameters that affect all TCP connections. Typical examples 133 include the enabling or disabling optional protocol features. 135 o Interface configuration: It can be useful to use different TCP 136 parameters on different interfaces, e.g., different device ports 137 or IP interfaces. In that case, TCP parameters can be part of the 138 interface configuration. Typical examples are the Maximum Segment 139 Size (MSS) or configuration related to hardware offloading. 141 o Connection parameters: Many implementations have means to 142 influence the behavior of each TCP connection, e.g., on the 143 programming interface used by applications. A typical example are 144 socket options in the socket API, such as disabling the Nagle 145 algorithm by TCP_NODELAY. In an application uses such an 146 interface, it is possible that the configuration of the 147 application or application protocol includes TCP-related 148 parameters. An example is the YANG model for BGP configuration 149 [I-D.ietf-idr-bgp-model]. 151 o Policies: Setting of TCP parameters can also be part of system 152 policies, templates, or profiles. An example would be the 153 preferences defined in the TAPS interface 154 [I-D.ietf-taps-interface]. 156 There is no ground truth for setting certain TCP parameters, and 157 traditionally different implementation have used different modeling 158 approaches. For instance, one implementation may define a given 159 configuration parameter globally, while another one uses per- 160 interface settings, and both approaches work well for the 161 corresponding use cases. Also, different systems may use different 162 default values. 164 In addition to configuration of the TCP protocol engine, a TCP 165 implementation typically also offers access to operational state and 166 statistics. This includes amongst others: 168 o Statistics: Counters for the number of active/passive opens, sent 169 and received segments, errors, and possibly other detailed 170 debugging information 172 o TCP connection table: Access to status information for all TCP 173 connections 175 o TCP listener table: Tnformation about all TCP listening endpoints 177 This document focuses solely on modeling basic TCP configuration 178 state. Operational state (see [RFC8342]) is outside the scope of 179 this specification. 181 The YANG model defined in this document extends a base model for TCP 182 clients and servers [I-D.ietf-netconf-tcp-client-server]. Similar to 183 the base model, this specification only defines YANG groupings. This 184 allows reuse of these groupings in different YANG data models. It is 185 intended that these groupings will be used either standalone or for 186 TCP-based protocols as part of a stack of protocol-specific 187 configuration models. 189 3.2. Basic TCP Configuration Parameters 191 There are a number of basic system parameters that are configurable 192 on many TCP implementations, even if not all TCP implementations may 193 indeed have exactly all these settings. Also, the syntax, semantics 194 and scope (e.g., global or interface-specific) can be different in 195 different system architectures. 197 The following list of fundamental parameters considers both TCP 198 implementations on hosts and on routers: 200 o Keepalives (see also [I-D.ietf-netconf-tcp-client-server]) 202 * Idle-time (in seconds): integer 204 * Probe-interval (in seconds): integer 206 * Max-probes: integer 208 o Maximum MSS (in byte): integer 210 o FIN timeout (in seconds): integer 212 o SACK (disable/enable): boolean 214 o Timestamps (disable/enable): boolean 216 o Path MTU Discovery (disable/enable): boolean 218 o ECN 220 * Enabling (disable/passive/active): enumeration 222 Some other parameters are also common but not ubiquitously supported, 223 or modeled in very different ways. Therefore, the following 224 attributes are not considered in this document: 226 o Delayed ACK timeout (in ms) 228 o Initial RTO value (in ms) 230 o Maximum number of retransmissions 232 o Window scaling 234 o Maximum number of connections 235 TCP can be implemented in different ways and design choices by the 236 protocol engine often affect configuration options. In a number of 237 areas there are major differences between different software 238 architectures. As a result, there are not many commonalities in the 239 corresponding configuration parameters: 241 o Window size: TCP stacks can either store window state variables 242 (such as the congestion window) in segments or in bytes. 244 o Buffer sizes: The memory management depends on the operating 245 system. As the size of buffers can vary over several orders of 246 magnitude, very different implementations exist. This typically 247 influences TCP flow control. 249 o Timers: Timer implementation is another area in which TCP stacks 250 may differ. 252 o Congestion control algorithms: Many congestion control algorithms 253 have configuration parameters, but except for fundamental 254 properties they often tie into the specific implementation. 256 This document only models fundamental system parameters that are 257 configurable on many TCP implementations, and for which the 258 configuration is reasonably similar. 260 3.3. Model Design 262 [[Editor's node: This section requires further work.]] 264 This document extends the YANG model "ietf-tcp-common" defined in 265 [I-D.ietf-netconf-tcp-client-server]. The exact modeling is TBD. 266 The intention is to define YANG groupings for all parameters so that 267 they can be used in different YANG models. 269 As an example, enabling the support of Selective Acknowledgements 270 (SACK) can be modelled as follows: 272 grouping tcp-sack-grouping { 273 description "Support of Selective Acknowledgements (SACK)"; 275 leaf sack { 276 type boolean; 277 default "true"; 279 description 280 "Enable support of Selective Acknowledgements (SACK)"; 281 } 282 } 284 A YANG model could then, for instance, import the YANG model "ietf- 285 tcp-common" as well as the model defined in this document as follows: 287 ... 288 grouping example-tcp-config { 289 description "Example TCP stack configuration"; 291 uses tcp-common-grouping; 292 uses tcp-sack-grouping; 293 } 294 ... 296 3.4. Tree Diagram 298 [[Editor's node: This section will be completed in follow-up versions 299 of this document.]] 301 This section provides a tree diagram [RFC8340] for the YANG module 302 defined in this document. 304 4. TCP Configuration YANG Model 306 [[Editor's node: This section is TBD.]] 308 5. IANA Considerations 310 [[Editor's node: This section will be completed in follow-up versions 311 of this document.]] 313 6. Security Considerations 315 The YANG module specified in this document defines a schema for data 316 that is designed to be accessed via network management protocols such 317 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 318 is the secure transport layer, and the mandatory-to-implement secure 319 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 320 is HTTPS, and the mandatory-to-implement secure transport is TLS 321 [RFC8446]. 323 The Network Configuration Access Control Model (NACM) [RFC8341] 324 provides the means to restrict access for particular NETCONF or 325 RESTCONF users to a preconfigured subset of all available NETCONF or 326 RESTCONF protocol operations and content. 328 7. References 330 7.1. Normative References 332 [I-D.ietf-netconf-tcp-client-server] 333 Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients 334 and TCP Servers", draft-ietf-netconf-tcp-client-server-02 335 (work in progress), July 2019. 337 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 338 RFC 793, DOI 10.17487/RFC0793, September 1981, 339 . 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, 343 DOI 10.17487/RFC2119, March 1997, 344 . 346 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 347 the Network Configuration Protocol (NETCONF)", RFC 6020, 348 DOI 10.17487/RFC6020, October 2010, 349 . 351 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 352 and A. Bierman, Ed., "Network Configuration Protocol 353 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 354 . 356 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 357 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 358 . 360 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 361 RFC 7950, DOI 10.17487/RFC7950, August 2016, 362 . 364 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 365 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 366 . 368 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 369 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 370 May 2017, . 372 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 373 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 374 . 376 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 377 Access Control Model", STD 91, RFC 8341, 378 DOI 10.17487/RFC8341, March 2018, 379 . 381 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 382 and R. Wilton, "Network Management Datastore Architecture 383 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 384 . 386 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 387 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 388 . 390 7.2. Informative References 392 [I-D.ietf-idr-bgp-model] 393 Jethanandani, M., Patel, K., and S. Hares, "BGP YANG Model 394 for Service Provider Networks", draft-ietf-idr-bgp- 395 model-06 (work in progress), June 2019. 397 [I-D.ietf-netmod-acl-model] 398 Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 399 "Network Access Control List (ACL) YANG Data Model", 400 draft-ietf-netmod-acl-model-21 (work in progress), 401 November 2018. 403 [I-D.ietf-opsawg-nat-yang] 404 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 405 S., and Q. Wu, "A YANG Module for Network Address 406 Translation (NAT) and Network Prefix Translation (NPT)", 407 draft-ietf-opsawg-nat-yang-17 (work in progress), 408 September 2018. 410 [I-D.ietf-taps-interface] 411 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 412 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 413 Abstract Application Layer Interface to Transport 414 Services", draft-ietf-taps-interface-03 (work in 415 progress), March 2019. 417 [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission 418 Protocol (SCTP) Management Information Base (MIB)", 419 RFC 3873, DOI 10.17487/RFC3873, September 2004, 420 . 422 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 423 the Transmission Control Protocol (TCP)", RFC 4022, 424 DOI 10.17487/RFC4022, March 2005, 425 . 427 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 428 the User Datagram Protocol (UDP)", RFC 4113, 429 DOI 10.17487/RFC4113, June 2005, 430 . 432 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 433 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 434 May 2007, . 436 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 437 Information Version 2 (SMIv2) MIB Modules to YANG 438 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 439 . 441 Appendix A. Acknowledgements 443 Michael Scharf is supported by the StandICT.eu project, which is 444 funded by the European Commission under the Horizon 2020 Programme. 446 Appendix B. Changes compared to previous versions 448 Changes compared to draft-scharf-tcpm-yang-tcp-01 450 o Alignment with [I-D.ietf-netconf-tcp-client-server] 452 o Removing backward-compatibility to the TCP MIB 454 o Additional co-author 456 Changes compared to draft-scharf-tcpm-yang-tcp-00 458 o Editorial improvements 460 Authors' Addresses 462 Michael Scharf 463 Hochschule Esslingen - University of Applied Sciences 464 Flandernstr. 101 465 Esslingen 73732 466 Germany 468 Email: michael.scharf@hs-esslingen.de 469 Vishal Murgai 470 Cisco Systems Inc 472 Email: vmurgai@cisco.com